Миграция виртуальной машины между узлами Proxmox VE

Пошаговая миграция виртуальной машины между узлами Proxmox VE: проверка кластера, хранилищ, сети, CPU и выполнение online или offline migration.

Миграция позволяет перенести виртуальную машину с одного узла Proxmox VE на другой без пересоздания VM.

Операция используется при:

  • обслуживании узла;
  • обновлении гипервизора;
  • перераспределении нагрузки;
  • освобождении хранилища;
  • замене оборудования;
  • подготовке к выключению узла.

В этой инструкции рассматривается только миграция одной виртуальной машины между узлами одного Proxmox-кластера.

Подходит для: Proxmox VE 8 и 9
Уровень сложности: средний
Время выполнения: зависит от размера дисков, памяти и скорости сети
Требуемый доступ: права управления VM и миграцией

Важное предупреждение

Перед миграцией:

  • создайте свежую резервную копию VM;
  • проверьте состояние кластера;
  • убедитесь, что оба узла доступны;
  • проверьте свободное место на целевом storage;
  • проверьте совместимость CPU;
  • убедитесь, что сетевые bridge и VLAN существуют на обоих узлах;
  • не запускайте одновременно backup, snapshot и migration;
  • не прерывайте задачу без необходимости.

Что будет рассмотрено

После выполнения инструкции можно будет:

  • проверить готовность кластера;
  • определить тип миграции;
  • выполнить online migration;
  • выполнить offline migration;
  • перенести диски на другое storage;
  • проверить сеть и CPU;
  • проверить VM после миграции;
  • диагностировать типичные ошибки.

Условия для миграции

Для миграции между узлами требуется:

  • оба узла состоят в одном Proxmox-кластере;
  • кластер имеет quorum;
  • целевой узел доступен;
  • VM ID уникален в кластере;
  • storage доступен либо поддерживается перенос локальных дисков;
  • сетевые bridge существуют на целевом узле;
  • процессоры совместимы;
  • firewall и VLAN настроены одинаково.

Проверка узлов кластера

Покажите состояние кластера:

pvecm status

Покажите узлы:

pvecm nodes

Ожидается:

Quorate: Yes

Каждый узел должен иметь статус online.

Проверка VM

Покажите список:

qm list

Проверьте статус:

qm status VM_ID

Покажите конфигурацию:

qm config VM_ID

Пример:

qm config 100

Проверка активных задач

Перед началом убедитесь, что VM не участвует в других операциях.

ps aux |
grep -E 'vzdump|qmigrate|qemu-img|pvesm' |
grep -v grep

В веб-интерфейсе:

Node → Tasks

Проверка хранилищ

pvesm status

Проверьте:

  • исходное storage;
  • целевое storage;
  • статус active;
  • свободное место;
  • доступность storage с обоих узлов.

Shared и local storage

Shared storage

Примеры:

Ceph RBD
NFS
iSCSI
shared LVM

Если диски VM находятся на общем storage, при миграции между узлами обычно переносится только состояние VM и оперативной памяти.

Local storage

Примеры:

local-lvm
local-zfs
directory storage

Если диск находится локально, его необходимо передать на storage целевого узла.

Это увеличивает время миграции и сетевую нагрузку.

Проверка дисков VM

qm config VM_ID |
grep -E '^(scsi|virtio|sata|ide|efidisk|tpmstate)[0-9]*:'

Пример:

scsi0: local-lvm:vm-100-disk-0,size=64G
efidisk0: local-lvm:vm-100-disk-1,size=4M

Нужно учесть все диски, включая:

  • EFI disk;
  • TPM state;
  • cloud-init disk;
  • дополнительные data-диски.

Проверка сети

Покажите сетевые устройства VM:

qm config VM_ID |
grep '^net'

Пример:

net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0,tag=100

На целевом узле должен существовать bridge:

ip link show vmbr0

Для VLAN-aware bridge:

grep -A10 'auto vmbr0' /etc/network/interfaces

Если используется VLAN Tag, конфигурация коммутатора и bridge должна совпадать.

Проверка CPU

Проверьте тип CPU VM:

qm config VM_ID |
grep '^cpu'

Тип host

cpu: host

даёт максимальную производительность, но может затруднить миграцию между узлами с разными процессорами.

Универсальный CPU type

Для совместимости можно использовать модель:

x86-64-v2-AES

или другую модель, поддерживаемую всеми узлами.

Не меняйте CPU type production-VM без проверки совместимости гостевой ОС.

Сравнение процессоров узлов

На каждом узле:

lscpu

Проверьте:

  • Vendor ID;
  • Model name;
  • Architecture;
  • Flags;
  • Virtualization;
  • количество CPU.

Для online migration особенно важна совместимость CPU-флагов.

Online и offline migration

Online migration

VM продолжает работать во время переноса.

Преимущества:

  • минимальный простой;
  • подходит для работающих сервисов;
  • переносится оперативная память.

Ограничения:

  • выше нагрузка на сеть;
  • требуется совместимость CPU;
  • операция может занять дольше при высокой активности VM;
  • некоторые конфигурации не поддерживают live migration.

Offline migration

VM останавливается перед переносом.

Преимущества:

  • более предсказуемая операция;
  • меньше требований к совместимости CPU;
  • проще для локальных дисков;
  • меньше риск рассинхронизации памяти.

Недостаток:

  • сервис недоступен во время миграции.

Создание резервной копии

Перед миграцией:

vzdump VM_ID   --storage BACKUP_STORAGE   --mode snapshot   --compress zstd

Дождитесь:

TASK OK

Online migration через веб-интерфейс

Выберите VM.

Нажмите:

Migrate

Укажите:

  • Target node;
  • Target storage при необходимости;
  • Online migration;
  • параметры сети миграции при наличии.

Нажмите:

Migrate

Следите за журналом задачи.

Offline migration через веб-интерфейс

Корректно остановите VM:

Shutdown

Проверьте статус:

stopped

Нажмите:

Migrate

Выберите целевой узел и storage.

Запустите задачу.

Online migration через CLI

qm migrate   VM_ID   TARGET_NODE   --online

Пример:

qm migrate   100   pve02   --online

Offline migration через CLI

Сначала остановите VM:

qm shutdown VM_ID

Проверьте:

qm status VM_ID

Выполните:

qm migrate   VM_ID   TARGET_NODE

Пример:

qm migrate   100   pve02

Перенос локальных дисков

Если VM использует local storage, может потребоваться указать:

--with-local-disks

Пример:

qm migrate   100   pve02   --online   --with-local-disks

Проверьте, поддерживается ли выбранная комбинация storage и режима миграции.

Указание целевого storage

Если имя storage отличается:

qm migrate   100   pve02   --online   --with-local-disks   --targetstorage local-zfs

Перед запуском проверьте:

pvesm status

Сеть миграции

В кластере можно выделить отдельную сеть для migration traffic.

Преимущества:

  • не перегружает management-сеть;
  • выше предсказуемость;
  • быстрее перенос локальных дисков и RAM;
  • меньше влияние на пользовательский трафик.

Настройка отдельной migration network требует отдельного проектирования.

Проверка пропускной способности

Между узлами можно проверить сеть:

На целевом узле:

iperf3 -s

На исходном:

iperf3 -c TARGET_NODE_IP

Если iperf3 отсутствует:

apt update
apt install -y iperf3

Тест создаёт нагрузку на сеть и должен запускаться в согласованное время.

Наблюдение за миграцией

В веб-интерфейсе:

Node → Tasks

Через CLI:

ps aux |
grep -E 'qmigrate|qemu-migrate|pvesm' |
grep -v grep

Сетевая нагрузка:

sar -n DEV 1

Дисковая нагрузка:

iostat -xz 1

Высокая активность VM

Если VM активно изменяет память, online migration может долго не завершаться.

Причины:

  • большая RAM;
  • высокая запись в память;
  • активная база данных;
  • интенсивный cache;
  • высокая сетевой трафик;
  • медленная migration network.

В таком случае может потребоваться согласованная offline migration.

Проверка завершения

В журнале задачи должна появиться строка:

TASK OK

Покажите список VM на целевом узле:

qm list

Проверьте статус:

qm status VM_ID

Проверьте конфигурацию:

qm config VM_ID

Проверка расположения VM

В кластере:

pvesh get /cluster/resources   --type vm

Для конкретной VM:

pvesh get /cluster/resources   --type vm |
grep -w VM_ID

В выводе должен быть указан целевой узел.

Проверка дисков после миграции

qm config VM_ID |
grep -E '^(scsi|virtio|sata|ide|efidisk|tpmstate)'

Проверьте storage каждого диска.

Для local storage на целевом узле:

pvesm list STORAGE_ID |
grep "vm-VM_ID"

Проверка VM после online migration

Проверьте доступность сервиса:

ping -c 3 VM_IP

Проверьте SSH:

ssh ADMIN_USER@VM_IP

Для веб-сервиса:

curl -I http://VM_IP

Проверьте QEMU Guest Agent:

qm agent VM_ID ping

Проверка гостевой ОС

Внутри VM:

uptime

Проверьте время:

timedatectl

Проверьте сеть:

ip -br addr
ip route

Проверьте сервисы:

systemctl --failed

Проверьте журнал:

journalctl -b -p err --no-pager

Проверка после offline migration

Если VM была остановлена, запустите:

qm start VM_ID

Откройте консоль и проверьте:

  • загрузку;
  • filesystem;
  • сеть;
  • приложение;
  • QEMU Guest Agent;
  • monitoring.

Проверка автозапуска

qm config VM_ID |
grep '^onboot'

Если необходимо:

qm set VM_ID   --onboot 1

Firewall после миграции

Проверьте:

  • Datacenter rules;
  • Node rules;
  • VM firewall;
  • IPSet;
  • Security Group;
  • сетевой интерфейс VM.

Правила уровня VM сохраняются, но node-level rules могут отличаться между узлами.

Локальные ISO и устройства

Миграции могут мешать:

  • локально подключённый ISO;
  • passthrough PCI;
  • USB passthrough;
  • physical disk passthrough;
  • локальный bind;
  • host-specific device.

Проверьте:

qm config VM_ID

Обратите внимание на:

hostpci
usb
args
ide2
sata

PCI passthrough

VM с:

hostpci0

обычно нельзя мигрировать online между обычными узлами.

На целевом узле должно быть совместимое устройство и конфигурация IOMMU.

Часто требуется выключить VM и изменить hardware mapping.

Локальный ISO

Если CD/DVD использует ISO на локальном storage исходного узла, миграция может завершиться ошибкой.

Отключите ISO:

qm set VM_ID   --ide2 none,media=cdrom

Сначала сохраните текущую конфигурацию.

Снапшоты

Проверьте:

qm listsnapshot VM_ID

Наличие снапшотов может ограничивать перенос локальных дисков между разными backend.

Не удаляйте снапшоты без backup и проверки.

Типичные проблемы

Ошибка CPU incompatibility

Проверьте CPU type:

qm config VM_ID |
grep '^cpu'

Сравните процессоры узлов:

lscpu

Для online migration используйте совместимую модель CPU.

Target storage не найден

Проверьте:

pvesm status

Storage должен быть:

  • доступен на целевом узле;
  • разрешён для Disk image;
  • иметь достаточно места.

Bridge не существует на целевом узле

Проверьте:

ip link show vmbr0

Имена bridge в конфигурации VM должны существовать на обоих узлах.

VM использует локальное устройство

Проверьте:

qm config VM_ID

Удалите или перенастройте:

  • ISO;
  • USB;
  • PCI passthrough;
  • physical disk;
  • host-specific mapping.

Online migration долго не завершается

Проверьте:

  • загрузку памяти VM;
  • скорость сети;
  • загрузку storage;
  • объём RAM;
  • dirty page rate.

При необходимости выполните offline migration.

После миграции нет сети

Проверьте:

  • bridge;
  • VLAN;
  • firewall;
  • physical uplink;
  • конфигурацию коммутатора;
  • MAC filtering.

После миграции storage inactive

Проверьте:

pvesm status

Убедитесь, что целевой узел имеет доступ к storage.

Возврат VM на исходный узел

Если после проверки требуется вернуть VM:

qm migrate   VM_ID   SOURCE_NODE   --online

Для local disks добавьте необходимые параметры.

Не запускайте обратную миграцию, пока текущая задача полностью не завершилась.

Безопасный порядок миграции

  1. Проверить backup.
  2. Проверить quorum.
  3. Проверить оба узла.
  4. Проверить CPU.
  5. Проверить bridge и VLAN.
  6. Проверить storage.
  7. Проверить локальные устройства.
  8. Выбрать online или offline mode.
  9. Запустить миграцию.
  10. Дождаться TASK OK.
  11. Проверить расположение VM.
  12. Проверить диски, сеть и приложение.
  13. Проверить monitoring и backup job.

Быстрый набор команд

Состояние кластера:

pvecm status
pvecm nodes

Проверка VM:

qm status VM_ID
qm config VM_ID

Online migration:

qm migrate   VM_ID   TARGET_NODE   --online

Offline migration:

qm shutdown VM_ID
qm migrate VM_ID TARGET_NODE

С локальными дисками:

qm migrate   VM_ID   TARGET_NODE   --online   --with-local-disks

Итог

После выполнения инструкции:

  • проверены кластер, CPU, сеть и storage;
  • выбрана online или offline migration;
  • перенесены локальные диски при необходимости;
  • проверено новое расположение VM;
  • проверены гостевая ОС, сеть и сервисы;
  • рассмотрены passthrough, ISO и snapshot;
  • разобраны типичные ошибки.

Миграцию следует считать завершённой только после проверки работы приложения и доступности всех дисков на целевом узле.

← Предыдущая статья Перенос виртуального диска между хранилищами в Proxmox VE Следующая статья → Настройка VLAN для виртуальной машины в Proxmox VE