Proxmox: пошаговое руководство по миграции виртуальных машин между серверами

Перенос виртуальной машины между хостами Proxmox VE - это штатная операция, которая решает задачи балансировки нагрузки, обслуживания оборудования и апгрейда серверов без длительных простоев. В этой статье вы получите готовые команды и проверенную последовательность действий для live-миграции (без остановки ВМ) и offline-миграции (с временным выключением). Материал охватывает настройку кластера, подключение общего хранилища, унификацию сетевых мостов и диагностику типовых ошибок. Все примеры протестированы на актуальных версиях Proxmox VE и ориентированы на практическое применение.

Live-миграция перемещает работающую ВМ на другой узел за счет копирования оперативной памяти и состояния процессора. Offline-миграция переносит выключенную ВМ между серверами, в том числе без кластера, через резервное копирование и восстановление. Выбор метода зависит от того, допускает ли сервис внутри ВМ даже кратковременную паузу. Если простой критичен - используйте live-миграцию. Если плановое обслуживание позволяет остановить ВМ на несколько минут - offline-метод проще и не требует общего хранилища.

Перед любой миграцией убедитесь, что на целевом сервере достаточно ресурсов CPU, RAM и дискового пространства. Рекомендуем сделать снапшот или резервную копию ВМ - это страховка от непредвиденных сбоев. Если вы переносите ВМ между гипервизорами разных типов, например с VMware или Hyper-V на Proxmox, обратитесь к руководству по миграции ВМ между Proxmox, Hyper-V и VMware, где разобрана конвертация дисков и настройка драйверов VirtIO.

Введение: когда и зачем нужна миграция ВМ в Proxmox

Миграция виртуальных машин - это инструмент повседневной эксплуатации, а не аварийная процедура. Администраторы переносят ВМ, чтобы освободить ресурсы на перегруженном узле, вывести сервер на плановое обслуживание, заменить оборудование или распределить нагрузку в кластере. Proxmox VE поддерживает два режима: live-миграцию работающей ВМ и offline-миграцию выключенной.

Live-миграция сохраняет активные TCP-соединения и состояние приложений. Она требует кластер из двух и более узлов и общее хранилище, доступное всем участникам. Offline-миграция выполняется либо внутри кластера с общим хранилищем, либо между независимыми серверами через экспорт и импорт резервной копии. Второй сценарий подходит для миграции между разными версиями Proxmox или при переносе на новый хост без настройки кластера.

Ключевые условия успешной миграции: идентичные имена сетевых мостов на всех узлах, совместимость процессоров (одинаковый вендор и флаги CPU), доступность хранилища на целевом узле. Нарушение любого из этих условий приводит к ошибкам, которые мы разберем в разделе диагностики.

Подготовка среды для миграции

Подготовка инфраструктуры - это фундамент, без которого миграция либо не запустится, либо завершится потерей связности ВМ. Три обязательных компонента: кластер Proxmox, общее хранилище и унифицированные сетевые мосты. Каждый компонент критичен для live-миграции. Для offline-миграции между независимыми серверами кластер и общее хранилище не нужны.

Создание и настройка кластера Proxmox

Кластер Proxmox VE объединяет узлы в единую систему управления с общим пространством конфигураций. Без кластера живая миграция невозможна. Создайте кластер на первом узле, затем добавьте остальные.

Шаг 1. Создание кластера на первом узле. Выполните команду на узле, который станет мастером:

pvecm create my-cluster

Замените my-cluster на имя вашего кластера. Команда генерирует ключи шифрования и инициализирует службу Corosync. Процесс занимает несколько секунд.

Шаг 2. Добавление остальных узлов. На каждом узле, который нужно подключить, выполните:

pvecm add <IP-адрес-первого-узла>

Система запросит пароль root первого узла. После успешного соединения узел получит конфигурацию кластера и синхронизирует файлы из /etc/pve/.

Шаг 3. Проверка статуса. На любом узле выполните:

pvecm status

Вывод должен показать Quorate: Yes и список всех узлов с флагом Online. Если кворум не собран, проверьте сетевую связность и открытые порты 5404-5405 UDP (Corosync) и 22 TCP (SSH).

Требования к версиям. Все узлы кластера должны работать на одной мажорной версии Proxmox VE. Разница в минорных версиях допустима, но не рекомендуется. Перед добавлением узла обновите пакеты: apt update && apt dist-upgrade.

Настройка общего хранилища (NFS, iSCSI, Ceph)

Общее хранилище (shared storage) - это пространство, доступное всем узлам кластера. При live-миграции диски ВМ не копируются, а остаются на общем хранилище. Узел-приемник просто получает доступ к тем же файлам. Выбор технологии зависит от бюджета, требований к производительности и отказоустойчивости.

NFS - простой в настройке файловый доступ. Подходит для тестовых сред и небольших продакшен-инсталляций. Минус: производительность упирается в сеть и NFS-сервер.

iSCSI - блочный доступ, который ВМ видит как локальный диск. Производительность выше, чем у NFS, но требуется настройка LVM на целевом узле. Подходит для сред с высокими IOPS.

Ceph - гиперконвергентное решение. Диски узлов объединяются в единый пул, данные реплицируются. Обеспечивает отказоустойчивость и высокую скорость, но требует минимум трех узлов и 10G сети для стабильной работы.

Пример настройки NFS. На NFS-сервере создайте экспорт:

echo "/srv/nfs-share 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
exportfs -a

В веб-интерфейсе Proxmox перейдите: Datacenter → Storage → Add → NFS. Укажите ID хранилища (например, nfs-shared), IP-адрес сервера и путь экспорта (/srv/nfs-share). Включите опцию Shared - она критична для миграции. Через CLI хранилище добавляется в файл /etc/pve/storage.cfg:

nfs: nfs-shared
        path /mnt/pve/nfs-shared
        server 192.168.1.100
        export /srv/nfs-shared
        content images,iso
        shared 1

Проверьте права доступа. Директория на NFS-сервере должна быть доступна на запись пользователю root с узлов Proxmox. Ошибка «Permission denied» при миграции почти всегда связана с no_root_squash или владельцем директории.

Унификация сетевых мостов и VLAN

После миграции ВМ может потерять сеть, если имена сетевых мостов на узлах различаются. ВМ привязана к имени моста (например, vmbr0), и если на целевом узле такого моста нет, сетевой интерфейс ВМ останется без подключения.

Проверка имен мостов. На каждом узле выполните:

ip link show | grep -E "vmbr|bond"

Сравните вывод. Имена должны совпадать. Если на одном узле мост называется vmbr0, а на другом vmbr1, приведите их к единому стандарту через файл /etc/network/interfaces.

Настройка VLAN-aware bridge. Рекомендуем использовать один мост, помеченный как VLAN-aware. Это упрощает конфигурацию и исключает расхождения. Пример конфигурации:

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.10/24
        gateway 192.168.1.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

После изменения конфигурации перезапустите сеть: systemctl restart networking. Убедитесь, что все узлы используют одинаковые имена мостов и номера VLAN. Это гарантирует, что ВМ сохранит сетевую связность после миграции.

Живая миграция (Live Migration) без прерывания работы

Live-миграция перемещает работающую ВМ между узлами кластера. Процесс состоит из трех фаз: копирование оперативной памяти в фоне, кратковременная пауза для синхронизации состояния CPU и регистров, переключение выполнения на целевой узел. Пауза длится миллисекунды и незаметна для приложений внутри ВМ при стабильной сети.

Миграция через веб-интерфейс

Самый простой способ для повседневных операций. В веб-интерфейсе Proxmox выберите ВМ в списке, нажмите правой кнопкой мыши и выберите «Migrate». В открывшемся диалоге укажите:

Target node - целевой узел кластера.
Target storage - общее хранилище, на котором находятся диски ВМ.
Online - флаг, разрешающий живую миграцию. Если флаг снят, ВМ будет остановлена, перенесена и запущена заново.

Нажмите «Migrate» и наблюдайте за прогрессом в Task Viewer. Задача отображает объем скопированной памяти и расчетное время завершения. При успехе ВМ появится на целевом узле в статусе «running».

Миграция из командной строки

CLI-метод незаменим для автоматизации и сценариев без доступа к GUI. Базовый синтаксис:

qm migrate <vmid> <target-node> --online --targetstorage <storage-id>

Пример переноса ВМ с ID 100 на узел pve2 с хранилищем nfs-shared:

qm migrate 100 pve2 --online --targetstorage nfs-shared

Ключ --online включает живую миграцию. Ключ --targetstorage указывает хранилище для дисков, если оно отличается от исходного. Дополнительные опции:

--migration_network <CIDR> - задает выделенную сеть для передачи памяти. Используйте для разделения трафика миграции и клиентского трафика.
--migration_type insecure - отключает шифрование. Ускоряет миграцию в доверенной сети, но передает данные открытым текстом.

Проверить статус задачи можно командой:

qm status <vmid> --verbose

Особенности живой миграции с локальными дисками

По умолчанию live-миграция требует, чтобы диски ВМ находились на общем хранилище. Если ВМ использует локальное хранилище (например, local-lvm), добавьте опцию --with-local-disks:

qm migrate 100 pve2 --online --with-local-disks --targetstorage local-lvm

Proxmox скопирует диски на целевой узел перед переключением. Это увеличивает время миграции и требует двойного дискового пространства на период копирования. Риски: если копирование прервется, ВМ останется на исходном узле, но возможны артефакты в виде незавершенных файлов на целевом узле. Перед такой миграцией обязательно создайте резервную копию ВМ.

Офлайн-миграция (Offline Migration) выключенных ВМ

Offline-миграция применяется, когда сервис внутри ВМ допускает остановку: плановое обслуживание, перенос между разными версиями Proxmox, миграция на новое оборудование. Метод проще live-миграции и не требует тонкой настройки кластера.

Миграция выключенной ВМ в кластере

Остановите ВМ: qm stop <vmid>. Затем запустите миграцию без флага --online:

qm migrate 100 pve2 --targetstorage nfs-shared

Через GUI: правый клик на ВМ → Migrate, снимите флаг «Online», укажите целевой узел и хранилище. Процесс быстрый, так как копируются только конфигурационные файлы и состояние дисков, но не оперативная память.

Перенос ВМ между независимыми серверами (без кластера)

Если серверы не объединены в кластер, используйте связку vzdump и qmrestore. Этот метод подходит для миграции на новый хост, между разными версиями Proxmox или при смене аппаратной платформы.

Шаг 1. Создание резервной копии на исходном сервере.

vzdump <vmid> --mode stop --compress zstd --storage local

Ключ --mode stop останавливает ВМ перед копированием, гарантируя целостность данных. Для минимального простоя используйте --mode snapshot, но он требует поддержки снапшотов на хранилище.

Шаг 2. Перенос файла дампа.

scp /var/lib/vz/dump/vzdump-qemu-<vmid>-*.vma.zst root@<target-ip>:/var/lib/vz/dump/

Шаг 3. Восстановление на целевом сервере.

qmrestore /var/lib/vz/dump/vzdump-qemu-<vmid>-*.vma.zst <new-vmid> --storage local-lvm

Ключ --storage указывает хранилище для дисков ВМ. Если нужно добавить ВМ в пул ресурсов, используйте --pool <pool-name>. После восстановления проверьте конфигурацию сети и запустите ВМ.

Диагностика и решение типовых ошибок при миграции

Ошибки при миграции чаще всего вызваны тремя причинами: проблемы с аутентификацией между узлами, недоступность хранилища на целевом узле, сетевые таймауты. Ниже - конкретные симптомы и способы исправления.

Ошибки аутентификации и прав доступа

Симптом: «Host key verification failed» или «Permission denied (publickey)».

Причина: SSH-ключи узлов не синхронизированы или повреждены. Proxmox использует SSH для внутренней коммуникации между узлами кластера.

Решение: На узле, где возникает ошибка, выполните:

pvecm updatecerts --force

Команда перегенерирует SSL-сертификаты и SSH-ключи, а затем распространит их по кластеру. Если проблема сохраняется, проверьте файл /etc/pve/priv/authorized_keys - он должен содержать публичные ключи всех узлов. Вручную скопируйте недостающие ключи или пересоздайте кластер.

Проблемы с хранилищем и дисками

Симптом: «storage 'X' is not available on target node» или «storage migration failed».

Причина: Хранилище не настроено на целевом узле, не смонтировано или имеет другой ID.

Решение: Проверьте, что хранилище с тем же ID существует на целевом узле: Datacenter → Storage. Для NFS убедитесь, что экспорт смонтирован: mount | grep nfs. Проверьте права доступа: пользователь root с узла Proxmox должен иметь возможность создавать файлы в директории хранилища. Для iSCSI проверьте, что LUN виден на целевом узле: lsblk. Если используется LVM, убедитесь, что группа томов активирована: vgchange -ay.

Сетевые ошибки и таймауты

Симптом: «migration aborted», «connection timed out», миграция зависает на этапе копирования памяти.

Причина: Высокая задержка или потеря пакетов между узлами, несовпадение MTU, блокировка портов фаерволом.

Решение: Проверьте задержку: ping -s 1472 <target-ip>. Если пакеты фрагментируются, уменьшите MTU на интерфейсах. Убедитесь, что порты 8000-8100 TCP открыты между узлами - они используются для передачи памяти. Для миграции с высокими объемами RAM увеличьте таймаут:

qm migrate 100 pve2 --online --migration_network 10.10.10.0/24 --migration_type insecure

Выделенная сеть миграции (--migration_network) изолирует трафик и предотвращает конфликты с клиентской нагрузкой. Отключение шифрования (insecure) ускоряет передачу в доверенных сетях.

Проверка работоспособности ВМ после миграции

Успешное завершение задачи миграции не гарантирует, что ВМ функционирует корректно. Выполните обязательный чек-лист проверок, чтобы убедиться в отсутствии скрытых проблем.

Запуск ВМ. Убедитесь, что ВМ стартует без ошибок. Проверьте статус: qm status <vmid>. Если ВМ не запускается, изучите логи: qm showcmd <vmid> --pretty и запустите вручную для отладки.
Сетевая доступность. Проверьте пинг до ВМ с внешнего хоста. Попробуйте подключиться по SSH или RDP. Если сеть не работает, сверьте имя моста в конфигурации ВМ (/etc/pve/qemu-server/<vmid>.conf) с именами мостов на целевом узле.
Состояние дисков. Внутри ВМ выполните fdisk -l или df -h, чтобы убедиться, что все диски видны и смонтированы. Проверьте файловую систему: fsck -n /dev/sda1.
Нагрузка на CPU и память. Сравните показатели до и после миграции: top, htop, free -m. Аномальный рост нагрузки может указывать на проблемы с драйверами или несовместимость CPU.
Логи ВМ. Просмотрите dmesg и journalctl -xe на наличие ошибок. Обратите внимание на предупреждения о смене процессора, таймингов или устройств.

Рекомендуем создать снапшот ВМ перед миграцией. Если после переноса возникли проблемы, откат к снапшоту займет секунды. Для комплексной стратегии миграции серверов, включая Docker-контейнеры и Kubernetes-кластеры, используйте пошаговое руководство и чек-лист для системных администраторов.

Заключение: лучшие практики и дальнейшие шаги

Успешная миграция ВМ в Proxmox VE держится на трех столпах: кластер с кворумом, общее хранилище с корректными правами и унифицированные сетевые мосты. Перед каждой миграцией создавайте резервную копию. Для live-миграции используйте выделенную сеть и отключайте шифрование, если это допустимо политиками безопасности. Для offline-миграции между независимыми серверами связка vzdump и qmrestore остается надежным и проверенным методом.

Если вы планируете масштабный переезд инфраструктуры, изучите выбор стратегии миграции: Rehost, Replatform или Refactor. Для сред с высокими требованиями к доступности обратитесь к руководству по миграции в отказоустойчивых системах. Если вы переносите ВМ между разными гипервизорами, используйте инструкцию по миграции между Proxmox, Hyper-V и VMware с готовыми командами конвертации дисков.

Регулярно обновляйте узлы Proxmox до актуальных версий, проверяйте состояние кластера через pvecm status и тестируйте миграцию на некритичных ВМ перед применением к продуктивным сервисам. Систематический подход и проверенные инструкции сокращают риски и делают миграцию предсказуемой операцией.