Жива міграція VM у Proxmox VE між нодами кластера

Жива міграція (Live Migration) дозволяє перенести працюючу VM з однієї ноди Proxmox на іншу без зупинки. Віртуальна машина продовжує працювати з мінімальним перериванням (зазвичай кілька мілісекунд).

Типи міграції

Вимоги для живої міграції

• Обидві ноди в одному кластері Proxmox
• Ідентичні (або сумісні) типи CPU
• Спільне сховище (Ceph, NFS, iSCSI) або локальне сховище з прапорцем --online
• Гігабітна мережа між нодами (бажано виділена)

Жива міграція через CLI

# Мігрувати VM 100 з поточної ноди на node2
qm migrate 100 node2 --online

# Мігрувати з локальним сховищем (копіювання дисків на льоту)
qm migrate 100 node2 --online --with-local-disks

# Мігрувати із зазначенням цільового сховища
qm migrate 100 node2 --online --targetstorage local-lvm

# Офлайн-міграція
qm migrate 100 node2

Міграція LXC-контейнерів

# Жива міграція контейнера
pct migrate 200 node2 --online

# Офлайн-міграція з копіюванням локальних томів
pct migrate 200 node2 --targetstorage local-lvm

Налаштування мережі міграції

# /etc/pve/datacenter.cfg
migration: type=secure,network=10.0.1.0/24

# Або через веб-інтерфейс
# Datacenter → Options → Migration Settings

Усунення помилок міграції

# Помилка: CPU types incompatible
# Рішення: використати сумісний тип CPU
qm set 100 --cpu x86-64-v2-AES

# Помилка: missing storage on target
# Рішення: перевірити доступність сховища на цільовій ноді
pvesm status

# Помилка: VM has local resources (USB passthrough, etc.)
# Рішення: вимкнути USB passthrough перед міграцією
qm set 100 --delete usb0

Помилки міграції, не пов'язані з CPU чи сховищем

Окрім несумісності CPU та відсутності сховища, трапляються помилки мережевого та системного рівня — вони менш очевидні, бо текст помилки вказує на симптом (розрив з'єднання, тайм-аут), а не на першопричину в конфігурації мережі чи сертифікатів кластера.

ERROR: migration aborted (duration 00:00:03): Failed to sync data - copy failed: unexpected end of file
kvm: -incoming tcp:0:60000: Failed to bind socket: Address already in use
ERROR: online migrate failure - client_migrate_wait: got timeout waiting for reply

• unexpected end of file: розрив з'єднання між нодами під час передавання — перевірте стабільність мережі та MTU, за наявності jumbo frames переконайтеся, що MTU збігається на обох нодах і комутаторі.
• Address already in use: порт для вхідної міграції зайнятий попередньою незавершеною спробою. Дочекайтеся завершення завислого завдання у списку завдань або перезапустіть pvedaemon на цільовій ноді.
• got timeout waiting for reply: цільова нода не відповідає по SSH-тунелю міграції — перевірте, що порт 22 і кластерні сертифікати між нодами гаразд (pvecm updatecerts).

Усі три помилки варто спершу шукати в журналах саме цільової ноди, а не вихідної: там же видно, чи встигла розпочатися передача пам'яті і на якому відсотку вона обірвалася.

Коли жива міграція не підходить

У технології є чіткі межі застосування — поза ними міграція або неможлива, або не дає заявлених гарантій, а спроби обійти обмеження зазвичай коштують дорожче за офлайн-перенесення.

• VM з прокинутим PCI/GPU пристроєм або статично виділеними hugepages — переноситься лише офлайн.
• Перенесення між різними кластерами Proxmox: штатна команда qm migrate працює тільки всередині одного кластера; для міжкластерного перенесення використовуйте експорт/імпорт VM або реплікацію через Proxmox Backup Server.
• Вузький канал між нодами за великого обсягу RAM: міграція може не встигати синхронізувати «брудні» сторінки пам'яті швидше, ніж VM їх змінює, і зависати в циклі досинхронізації.

Перевірка результату міграції

Після перенесення переконайтеся, що VM справді працює на новій ноді і не втратила стан.

# На якій ноді зараз перебуває VM
pvesh get /cluster/resources --type vm | grep -A2 '"vmid": 100'

# Статус і аптайм VM після перенесення
qm status 100 --verbose

# Перевірка журналу останнього завдання міграції
pvesh get /nodes/node2/tasks --typefilter qmigrate --limit 1

Якщо аптайм VM не скинувся, а агент повідомляє актуальну IP-адресу — міграція пройшла без втрати стану. Загальні принципи побудови відмовостійкої інфраструктури описані в статті налаштування кластера Proxmox VE.

Часті питання

Чи можна живцем мігрувати VM із прокинутим GPU або іншим PCI-пристроєм?

Ні, жива міграція таких VM не підтримується: пристрій фізично прив'язаний до конкретної ноди, і гіпервізор не здатен перенести його стан на інший сервер без зупинки. Єдиний варіант для VM із PCI passthrough — офлайн-міграція з повною зупинкою машини, перенесенням конфігурації і повторним підключенням пристрою вже на цільовій ноді.

Чим міграція зі спільним сховищем відрізняється від міграції з локальними дисками?

За спільного сховища (Ceph, NFS, iSCSI) переноситься лише стан пам'яті та процесора, а диски фізично лишаються на місці й просто стають видимими новій ноді. За локального сховища диски VM копіюються на цільову ноду прямо під час міграції за допомогою прапорця --with-local-disks, що займає помітно довший час і дужче навантажує мережу.

Чи можна перенести VM з одного кластера Proxmox до іншого?

Штатна команда міграції працює лише в межах одного кластера і не вміє переносити VM між різними кластерами Proxmox. Для перенесення між незалежними кластерами застосовують експорт і подальший імпорт конфігурації VM або репліку через Proxmox Backup Server — обидва способи потребують додаткових кроків порівняно зі звичайною командою міграції.

Чи зупиняється VM хоча б на секунду під час живої міграції?

Формально так, але переривання настільки коротке — зазвичай кілька мілісекунд, — що застосунки та користувачі майже не помічають його. У цей момент гіпервізор перемикає виконання процесора з вихідної ноди на цільову вже тоді, коли основний обсяг пам'яті синхронізовано, тому мережеві з'єднання всередині VM, зазвичай, не рвуться.