Короткий ответ

Live-migration требует: целевой узел в кластере с кворумом, совместимый CPU type, доступ к дискам 101 (shared или явное копирование local), сеть миграции без обрыва, отсутствие PCI passthrough. Читайте Task log, не жмите Retry 10 раз. Offline migrate проще по CPU, но даёт простой.

Не мигрируйте на узел, который выпал или без quorum.

Симптомы и как отличить

Типичная картина:

  • progress 90% и abort;
  • ошибка про local disk / storage not available на цели;
  • kvm: warning: host doesn't support requested feature;
  • после abort VM осталась на pve1 (хорошо) или lock.

Отличия:

Что видноКуда
Целевой storage красныйХранилище
VM не стартует уже на исходномСтарт
Сеть гостя после успешного migrateСеть VM / VLAN

Возможные причины

  1. Диск на local-lvm pve1, на pve2 тома нет, online без disk migrate.
  2. cpu: host на разном железе.
  3. Сеть миграции = загруженный 1 Гбит вместе с NFS.
  4. hostpci, USB passthrough, local CD-ROM.
  5. RAM огромная, timeout.
  6. Firewall режет порты миграции между узлами.

Диагностика

pveversion
pvecm status
qm status 101
qm config 101
pvesm status

На обоих узлах pvesm status для storage дисков 101. CPU:

qm config 101 | grep -E '^cpu:|^numa:|^hostpci|^usb'
grep -E 'model name|Flags' /proc/cpuinfo | head

Сеть: ping между адресами migration (если задан dedicated). Журнал задачи Migrate.

Решение

Сценарий A. Local disk

Либо shared storage (NFS/iSCSI/ZFS replica не есть shared), либо migrate с опцией переноса диска / offline. Для обновления узла чаще: migrate на shared, патч, обратно.

Сценарий B. CPU type

Выключите VM (окно) и поставьте общий тип x86-64-v2-AES (дефолт PVE 8) на оба узла для этой VM. host оставляйте, только если железо идентично или migration не нужна.

Сценарий C. Passthrough

Live нельзя. Окно: stop, migrate offline или уберите hostpci0 на время.

Сценарий D. Сеть/таймаут

Выделите migration network, увеличьте timeout/bandwidth в разумных пределах, снизьте нагрузку IO. Не режьте SSH между узлами — миграция идёт по API/ssh/каналам PVE.

Сценарий E. CD-ROM и cloudinit

ISO должен быть доступен на цели или отвяжите CD. Cloudinit диск — на storage, видимом цели.

Что именно копируется и зачем смотреть оба узла

Live migration копирует RAM итерациями, затем короткий freeze. Если диск local, PVE должен сначала (или параллельно, в зависимости от опций) перенести том на pve2. Ошибка storage на цели на 5% — диск, не CPU. Ошибка на 99% — часто сеть/итерации памяти не сходятся из-за write-heavy гостя.

qm config 101 | grep -E 'cpu:|numa|scsi0|net0|hostpci|tpmstate|balloon'
pvesm status
ip -br addr
grep -E 'migration|keyboard' /etc/pve/datacenter.cfg

tpmstate на local storage мешает так же, как диск. CD-ROM local:iso/... должен резолвиться на цели. cpu: host + разные generation Xeon/EPYC — abort с feature list в логе: читайте какой флаг, не «увеличьте RAM».

Сеть миграции забитая vzdump: либо другое окно, либо migration_network. Не поднимайте bandwidth безмерно на 1 Гбит вместе с NFS: задушите storage и миграция всё равно сорвётся.

После abort всегда qm status 101 на обоих узлах. Два running — стоп оба, разбор диска. Один running на источнике — нормальный abort.

Как проверить, что проблема устранена

qm status 101
# на целевом узле
hostname

VM running уже на pve2, на pve1 её нет в running. Пинг гостя жив (live). Конфиг один в /etc/pve. Обратная миграция на pve1 проходит. Lock нет.

Перед migrate сверьте pveversion qemu-server на источнике и цели. Смесь 8.2/8.3 обычно живёт коротко, но notes к конкретным qemu читают заранее. Отключите HA на 101 на время ручной миграции, если HA пытается вернуть VM на pve1.

Локальный tpmstate/efidisk на local-lvm — те же ограничения, что scsi0: цель должна принять том. Если live нельзя, планируйте offline в том же change, что и патч узла. Не обещайте «без простоя» при passthrough GPU: это всегда stop.

Если не помогло

  • После abort диск-двойник на цели: не включайте вторую VM; удаляйте leftover только когда оригинал точно на источнике.
  • HA конфликтует с ручным migrate — учтите политика HA.
  • Encrypted/TPM state: смотрите версию PVE 8 и ограничения live для tpmstate.
  • Разный machine: (i440fx/q35) обычно мигрирует, проблемы чаще в CPU/disk.
  • Обновление: не мигрируйте на узел сильно новее/старше без чтения notes.

Профилактика

  • Единый CPU type в кластере.
  • Shared storage для VM, которые ездят.
  • Dedicated migration link.
  • Запрет passthrough на «ездящих» VM.
  • Тестовая миграция до патч-окна.
  • Одинаковые имена vmbr0 и VLAN trunk на всех узлах, куда может уехать 101.
  • Снять снимки и local CD-ROM перед окном migrate; HA не должен возвращать VM на патчущийся pve1.

FAQ

Online vs offline?

Online — живая. Offline — выключенная, проще для дисков/CPU. Для патча ядра часто достаточно live, если диски shared.

Нужен ли одинаковый pveversion?

Желательно в пределах одной ветки 8.x. Слишком большой разрыв qemu — риск. Читайте wiki PVE про mixed-version.

migration_network в datacenter.cfg?

Да, если хотите отделить трафик. Пропишите сеть, которая реально маршрутизируется между узлами.

Можно ли мигрировать с snapshots?

Иногда мешают. Удалите лишние снимки заранее (snapshot).

RAM balloon во время live?

Может удлинять итерации. Для окна зафиксируйте память.

Нужно ли одинаковое количество NIC на pve1 и pve2 для live-migration?

Имена bridge должны существовать на цели (vmbr0). Число физических NIC может отличаться, если мосты собраны. Нет vmbr0 на цели — миграция откроет VM без сети или упадёт. Сверьте interfaces до окна.