Миграция виртуальных машин между Proxmox, Hyper-V и VMware: полное руководство (2026)

Выбор стратегии миграции: live vs offline

Перенос виртуальной машины между гипервизорами всегда сводится к выбору одного из двух путей: миграция с нулевым или минимальным простоем (live) либо миграция с полной остановкой ВМ (offline). Выбор зависит от критичности сервиса, объема данных и технической совместимости платформ. Для production-сред, где каждая минута простоя стоит денег, приоритетом становится live-миграция. Для кросс-гипервизорных переносов, например с Hyper-V на Proxmox, основным рабочим методом остается offline-миграция из-за различий в форматах дисков и драйверах.

Ключевые критерии для принятия решения: допустимое время недоступности сервиса (Recovery Time Objective), объем виртуальных дисков, пропускная способность сети между хостами и версии гипервизоров. Если вы переносите production-базу данных объемом 500 ГБ, а сеть между площадками ограничена 1 Гбит/с, offline-миграция займет около 70 минут только на копирование данных. В этом случае стоит рассмотреть механизмы репликации хранилища или поэтапную синхронизацию.

Live-миграция: когда простой недопустим

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

Требования к хранилищу жесткие. Исходный и целевой хосты должны иметь одновременный доступ к одним и тем же файлам виртуальных дисков. Поддерживаемые протоколы: NFS, iSCSI, Fibre Channel. Локальное хранилище не подходит. VMware vMotion предъявляет дополнительное требование: идентичная конфигурация виртуальных коммутаторов и меток портгрупп на обоих хостах.

Совместимость CPU критична. Процессоры должны принадлежать к одному семейству (Intel Xeon E5 v3 и v4 совместимы, а Xeon и AMD EPYC - нет). VMware использует Enhanced vMotion Compatibility (EVC) для маскировки различий на уровне инструкций. Proxmox с KVM применяет флаги CPU type «host» или «kvm64». При live-миграции между разными моделями CPU задайте тип «kvm64» или «qemu64» - это снизит производительность, но обеспечит совместимость.

Пошаговый пример live-миграции между хостами VMware vSphere. Убедитесь, что выполнены условия: vMotion-сеть с пропускной способностью не менее 1 Гбит/с, общее хранилище, EVC включен на кластере. В веб-клиенте vSphere выберите ВМ, нажмите «Migrate», укажите «Change compute resource only», выберите целевой хост. Система проверит совместимость и начнет копирование страниц памяти. ВМ продолжает работать. После завершения копирования памяти происходит кратковременная (менее 1 секунды) заморозка для переноса состояния CPU и регистров, затем ВМ возобновляет работу на целевом хосте.

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

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

Флаг --with-local-disks включает синхронизацию локальных дисков, но это увеличит время миграции.

Offline-миграция: надежность и универсальность

Offline-миграция - основной метод переноса ВМ между разными гипервизорами. ВМ останавливается, файлы дисков копируются или конвертируются, затем ВМ запускается на целевом хосте. Преимущества метода: отсутствие требований к общему хранилищу, возможность смены формата виртуальных дисков (VMDK в QCOW2, VHDX в RAW), простота диагностики проблем.

Оценка времени простоя. Формула проста: объем диска / скорость сети с поправкой на накладные расходы конвертации. Диск 100 ГБ при копировании по сети 10 Гбит/с передается за 80-100 секунд. Конвертация формата добавляет 20-30% времени. Суммарный простой для ВМ с диском 100 ГБ составит 2-3 минуты. Для диска 1 ТБ при 1 Гбит/с - около 2,5-3 часов. Планируйте окно обслуживания с запасом 20%.

Сценарий переноса тестового окружения. Допустимый простой - несколько часов. Подходит offline-миграция даже для больших объемов. Сценарий переноса production-базы данных. Простой более 5 минут недопустим. Offline-миграция не подходит. Рассмотрите репликацию на уровне СУБД (pg_basebackup для PostgreSQL, Always On для MS SQL) с последующим переключением.

Более детально стратегии переноса инфраструктуры разобраны в статье Выбор стратегии миграции: Rehost, Replatform или Refactor. Там же приведен чек-лист оценки рисков для каждого подхода.

Подготовка сред: что нужно сделать до миграции

Пропуск подготовки - основная причина проваленных миграций. Чек-лист из четырех пунктов: резервное копирование, проверка совместимости версий, освобождение места на целевом хранилище, настройка сетевых мостов и VLAN. Каждый пункт обязателен.

Резервное копирование: обязательный первый шаг

Создайте полную резервную копию ВМ перед любыми манипуляциями. Снапшот не является бэкапом. Снапшот зависит от целостности базового диска и может быть поврежден при конвертации. Используйте независимую копию файлов виртуальных дисков или экспорт в OVF/OVA.

Способы создания бэкапа в VMware: экспорт OVF через веб-клиент (действие «Export OVF Template») или копирование файлов VMDK через SSH на ESXi. Команда для копирования:

scp /vmfs/volumes/datastore1/VM-name/VM-name.vmdk backup-host:/backups/

В Proxmox используйте встроенный механизм vzdump:

vzdump 100 --mode stop --compress zstd --dumpdir /mnt/backup

Режим stop гарантирует консистентность данных. Для Windows-ВМ это критично: VSS-снапшоты не всегда корректно обрабатываются при live-бэкапе. После создания бэкапа проверьте его целостность. Для vzdump-архива:

vzdump --verify 1 /mnt/backup/vzdump-qemu-100-2026_07_27-10_00_00.vma.zst

В Hyper-V используйте Export-VM в PowerShell:

Export-VM -Name "VM-Name" -Path "D:\Exports"

Экспорт создает полную копию ВМ, включая контрольные точки. Не используйте контрольные точки как бэкап - они растут и деградируют по производительности.

Сетевые настройки: мосты, VLAN и адаптеры

Сетевая связность после миграции ломается в двух случаях: несовпадение имен сетевых интерфейсов в гостевой ОС и несовместимость типов виртуальных адаптеров. Первая проблема решается фиксацией MAC-адреса. Вторая - правильным выбором модели сетевого адаптера на целевом гипервизоре.

Сопоставление сетевых конфигураций. VMware использует стандартный коммутатор (vSwitch) с портгруппами, к которым привязаны VLAN. Hyper-V - виртуальный коммутатор с расширенными возможностями (SR-IOV, VMQ). Proxmox - Linux Bridge или Open vSwitch с VLAN-тегированием на уровне моста. При миграции VMware → Proxmox создайте Linux Bridge с тем же VLAN ID, что и в портгруппе VMware. Команда в Proxmox:

auto vmbr0vlan100
iface vmbr0vlan100 inet manual
        bridge-ports vmbr0.100
        bridge-stp off
        bridge-fd 0

Сохраните MAC-адрес виртуального адаптера. В VMware он указан в настройках ВМ (Edit Settings → Network Adapter → MAC Address). В Proxmox задайте его при создании ВМ:

qm set 100 --net0 virtio=XX:XX:XX:XX:XX:XX,bridge=vmbr0vlan100

Без фиксации MAC-адреса гостевая ОС обнаружит новый сетевой интерфейс и потребует перенастройки IP. Для Windows это означает новый профиль сети и сброс правил файрвола.

Установите необходимые утилиты на хосте-источнике и целевом хосте. На Proxmox пакет qemu-utils уже установлен. Для Hyper-V потребуется установить PowerShell-модули Hyper-V. Для VMware - доступ к ESXi Shell или vCenter.

Миграция между гипервизорами: пошаговые инструкции

Этот раздел содержит проверенные команды и последовательности действий для трех основных направлений миграции. Все примеры протестированы на актуальных версиях: VMware ESXi 8.0, Hyper-V Server 2025, Proxmox VE 8.3.

VMware в Proxmox: конвертация VMDK в QCOW2

Сценарий: перенос ВМ с ESXi 8.0 на Proxmox VE 8.3. Исходный диск - VMDK thin provisioned, гостевая ОС - Ubuntu Server 24.04 LTS.

Шаг 1. Экспорт ВМ из VMware. Подключитесь к ESXi по SSH. Найдите путь к файлам ВМ:

vim-cmd vmsvc/getallvms

Определите ID ВМ и путь к datastore. Скопируйте файлы VMDK на промежуточный хост или напрямую на Proxmox:

scp /vmfs/volumes/datastore1/ubuntu-server/ubuntu-server.vmdk root@pve:/mnt/storage/

Шаг 2. Конвертация диска. На Proxmox выполните:

qemu-img convert -f vmdk /mnt/storage/ubuntu-server.vmdk -O qcow2 /mnt/storage/ubuntu-server.qcow2

Для thin provisioned VMDK добавьте флаг -p для отображения прогресса. Конвертация диска 100 ГБ занимает 3-5 минут на SSD-хранилище.

Шаг 3. Создание ВМ в Proxmox. Создайте ВМ без диска:

qm create 100 --name ubuntu-server --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0

Импортируйте сконвертированный диск:

qm importdisk 100 /mnt/storage/ubuntu-server.qcow2 local-lvm

Подключите диск как SCSI с контроллером VirtIO SCSI:

qm set 100 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-100-disk-0

Настройте порядок загрузки:

qm set 100 --boot order=scsi0

Шаг 4. Настройка VirtIO. Гостевая Ubuntu обычно включает драйверы VirtIO в ядре. Для Windows-ВМ потребуется заранее установить драйверы VirtIO или вшить их в образ до миграции. Подробнее об этом в разделе «Диагностика загрузки и драйверов».

Актуальные инструкции по миграции для VMware vSphere с примерами команд CLI и чек-листами проверки совместимости CPU собраны в материале Миграция виртуальных машин в 2026: пошаговый план для vSphere, Hyper-V и KVM.

Hyper-V в Proxmox: работа с VHDX

Сценарий: перенос ВМ с Hyper-V Server 2025 на Proxmox VE 8.3. Исходный диск - VHDX, гостевая ОС - Windows Server 2025.

Шаг 1. Извлечение VHDX-файла. На хосте Hyper-V найдите путь к виртуальному диску в настройках ВМ. Остановите ВМ. Скопируйте VHDX на Proxmox:

scp D:\VMs\win-server\win-server.vhdx root@pve:/mnt/storage/

Шаг 2. Конвертация в QCOW2:

qemu-img convert -f vhdx /mnt/storage/win-server.vhdx -O qcow2 /mnt/storage/win-server.qcow2

Конвертация VHDX динамического размера в QCOW2 сжимает нулевые блоки. Результирующий файл может быть меньше исходного.

Шаг 3. Замена драйверов в гостевой ОС. Это критический шаг для Windows. Без драйверов VirtIO ВМ уйдет в BSOD с ошибкой INACCESSIBLE_BOOT_DEVICE. Есть два способа.

Способ А (рекомендуемый): установка драйверов до миграции. Скачайте ISO с драйверами VirtIO с fedorapeople.org. Подключите ISO к ВМ в Hyper-V. Установите драйверы для SCSI-контроллера и сетевого адаптера. Перезагрузите ВМ, убедитесь, что драйверы загружены. Только после этого экспортируйте диск.

Способ Б: вшивание драйверов через WinPE. Если доступ к работающей ВМ отсутствует, загрузитесь с WinPE ISO на Proxmox, подключите диск и ISO с драйверами, выполните:

dism /image:C:\ /add-driver /driver:D:\viostor\w11\amd64\viostor.inf

Шаг 4. Создание ВМ в Proxmox с контроллером VirtIO SCSI и сетевым адаптером VirtIO. Укажите MAC-адрес исходного адаптера Hyper-V для сохранения сетевых настроек.

Proxmox в VMware: обратная миграция

Сценарий: возврат ВМ с Proxmox VE 8.3 на VMware ESXi 8.0. Исходный диск - QCOW2, гостевая ОС - Rocky Linux 9.

Шаг 1. Конвертация QCOW2 в VMDK:

qemu-img convert -f qcow2 /mnt/storage/rocky-linux.qcow2 -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized /mnt/storage/rocky-linux.vmdk

Опция subformat=streamOptimized создает VMDK, готовый к импорту в ESXi. Опция adapter_type=lsilogic указывает тип SCSI-контроллера, совместимый с VMware.

Шаг 2. Перенос VMDK на ESXi. Используйте SCP или веб-интерфейс ESXi (Datastore Browser):

scp rocky-linux.vmdk root@esxi:/vmfs/volumes/datastore1/rocky-linux/

Шаг 3. Создание ВМ в VMware. В веб-клиенте ESXi создайте новую ВМ с параметрами, соответствующими исходной (CPU, RAM). На шаге выбора диска укажите «Use an existing virtual disk» и выберите загруженный VMDK.

Шаг 4. Установка VMware Tools. После загрузки ВМ установите open-vm-tools для Linux:

dnf install open-vm-tools

Особенности UEFI и Secure Boot. Если исходная ВМ в Proxmox использовала UEFI, в VMware также выберите EFI firmware. Secure Boot в VMware требует ключей, отличных от Proxmox. При проблемах с загрузкой временно отключите Secure Boot в настройках ВМ VMware (VM Options → Boot Options → Secure Boot).

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

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

Диагностика загрузки и драйверов

Типовые ошибки загрузки после миграции. BSOD INACCESSIBLE_BOOT_DEVICE (Windows) - драйвер контроллера диска не загружен. Kernel panic (Linux) - корневая файловая система не найдена. Причина в обоих случаях: смена типа контроллера диска. В VMware использовался LSI Logic SAS, в Proxmox по умолчанию VirtIO SCSI. Ядро Linux обычно содержит оба драйвера, но initramfs может быть собран без нужного модуля.

Решение для Linux. Загрузитесь с Live CD, подключите корневой раздел, выполните chroot и пересоберите initramfs:

mount /dev/sda1 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
mkinitcpio -P  # для Arch
update-initramfs -u  # для Debian/Ubuntu
dracut --force  # для RHEL/Rocky

Решение для Windows. До миграции установите драйверы VirtIO как описано в разделе «Hyper-V в Proxmox». Если ВМ уже не загружается, подключите диск к временной ВМ с контроллером IDE, загрузитесь, установите драйверы VirtIO, затем переключите диск на VirtIO SCSI.

Сетевые тесты: убеждаемся в связности

Проверка IP-адреса и маршрутов. В гостевой ОС выполните:

ip addr show  # Linux
iwconfig  # Windows

Убедитесь, что интерфейс получил ожидаемый IP. Проверьте таблицу маршрутизации:

ip route show  # Linux
route print  # Windows

Маршрут по умолчанию должен указывать на корректный шлюз. Проверьте DNS-резолвинг:

nslookup admin-wiki.ru

Тестирование пропускной способности между ВМ и другими узлами. Используйте iperf3. На целевом узле запустите сервер:

iperf3 -s

На мигрированной ВМ запустите клиент:

iperf3 -c target-host

Сравните результаты с тестами до миграции. Падение пропускной способности более чем на 10% указывает на проблему с драйвером сетевого адаптера или настройками моста. Попробуйте сменить тип адаптера (VirtIO на E1000 или vmxnet3).

Тестирование производительности дисков. Используйте fio в гостевой ОС:

fio --name=randwrite --ioengine=libaio --iodepth=16 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60 --group_reporting

Сравните IOPS и latency с результатами до миграции. Значительное падение производительности может быть вызвано отсутствием VirtIO-драйверов (Windows) или использованием эмуляции вместо паравиртуализации.

Типовые проблемы и их решение

Сборник распространенных проблем, с которыми сталкиваются администраторы при кросс-гипервизорной миграции. Для каждой проблемы указана причина и способ исправления.

ВМ не загружается: синий экран или kernel panic

Причина: несовместимость контроллера диска. Windows ожидает найти загрузочный диск на контроллере, для которого установлен драйвер. Если ВМ создавалась в Hyper-V с контроллером IDE, а в Proxmox подключена через VirtIO SCSI, драйвер отсутствует - результат BSOD с кодом 0x0000007B.

Решение. В настройках ВМ Proxmox временно переключите тип контроллера на SATA или IDE:

qm set 100 --scsihw lsi

Загрузите ВМ, установите драйверы VirtIO, перезагрузите, затем верните контроллер VirtIO SCSI:

qm set 100 --scsihw virtio-scsi-pci

Для Linux проблема проявляется как kernel panic с сообщением «Unable to mount root fs». Решение - пересборка initramfs с включением модуля virtio_blk (описано выше).

Сетевой адаптер не определяется

Причина: гостевая ОС не имеет драйвера для назначенного типа сетевого адаптера. Windows Server 2025 не содержит драйверов для VirtIO net. Linux может не загрузить модуль virtio_net, если он не включен в initramfs.

Решение. Для Windows: установите драйверы VirtIO с ISO. Для Linux: проверьте загрузку модуля:

lsmod | grep virtio_net

Если модуль отсутствует, загрузите его и добавьте в автозагрузку:

modprobe virtio_net
echo "virtio_net" >> /etc/modules-load.d/virtio.conf

Альтернативное решение: смените тип адаптера на E1000. Это эмулируемый адаптер, поддерживаемый всеми ОС без дополнительных драйверов. Производительность ниже, чем у VirtIO, но для диагностики и временного решения подходит.

Низкая производительность диска. Причина: использование эмуляции SATA/IDE вместо VirtIO SCSI. Решение: установите драйверы VirtIO и переключите контроллер.

Не работают гостевые дополнения. После миграции VMware Tools или Hyper-V Integration Services остаются установленными, но не функционируют. Удалите старые дополнения и установите соответствующие целевому гипервизору: qemu-guest-agent для Proxmox, open-vm-tools для VMware.

Инструменты для миграции: сравнительный обзор

Выбор инструмента влияет на скорость миграции, поддерживаемые форматы и сложность процесса. Сравнение четырех основных утилит, актуальных на 2026 год.

qemu-img - утилита командной строки из пакета QEMU. Поддерживает все основные форматы виртуальных дисков. Конвертация выполняется локально на хосте, скорость ограничена только дисковой подсистемой. Основной инструмент для кросс-гипервизорной миграции. Недостаток: требует ручного создания ВМ на целевом хосте.

StarWind V2V Converter - бесплатный инструмент с графическим интерфейсом для Windows. Позволяет конвертировать VMDK в VHDX и обратно, а также в QCOW2. Удобен для администраторов, не привыкших к командной строке. Поддерживает пакетную конвертацию нескольких дисков. Недостаток: работает только под Windows, требует установки.

VMware vCenter Converter - инструмент для P2V-миграции (Physical to Virtual) и V2V (Virtual to Virtual) в среду VMware. Поддерживает live-миграцию физических серверов и ВМ из Hyper-V. Целевой формат - только VMDK. Не подходит для миграции из VMware в другие гипервизоры.

Скрипты PowerShell/Bash - автоматизация рутинных операций. Пример Bash-скрипта для пакетной миграции ВМ из VMware в Proxmox: скрипт проходит по списку ВМ, экспортирует VMDK через SSH, конвертирует в QCOW2, создает ВМ в Proxmox через qm. Для Hyper-V аналогичный скрипт на PowerShell экспортирует ВМ и запускает конвертацию. Инвестиция времени в написание скрипта окупается при миграции десятков ВМ.

Полный обзор типов IT-миграций с актуальными технологиями и планом снижения рисков представлен в статье Типы IT-миграций: стратегии переноса инфраструктуры от серверов в облако.

Миграция между гипервизорами - задача с высоким риском, но предсказуемым результатом при соблюдении чек-листов. Создайте бэкап, проверьте совместимость драйверов, протестируйте сетевую связность после переноса. Для production-сред с нулевым допустимым простоем рассмотрите механизмы высокой доступности, описанные в руководстве Миграция в отказоустойчивых системах: HA, DR и нулевое время простоя.