Живая миграция 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, как правило, не рвутся.