Миграция виртуальных машин с Hyper-V на Proxmox без простоя

За 2025 год через мои руки прошло одиннадцать миграций с Hyper-V на Proxmox VE — от трёх ВМ в маленькой бухгалтерской фирме до тридцати двух в проектном бюро на Тульской. С опытом сложилась чёткая последовательность шагов и набор грабель, которые я обхожу автоматически. Делюсь полным конвейером: какие команды выполняю, в каком порядке, что проверяю, и как удержать простой бизнеса в пределах нерабочего ночного окна.

Почему вообще ушли с Hyper-V

Hyper-V — нормальный гипервизор. Я не буду повторять стереотипные обиды на Microsoft. У него есть две объективные слабости в реалиях РФ 2026 года.

Первое. Лицензии Windows Server Datacenter, без которых Hyper-V в проде не имеет смысла, продаются через нестабильный канал. Один из моих клиентов в декабре 2025 не смог продлить Datacenter на 32 ядра за разумные деньги — партнёр выкатил счёт на 1,8 миллиона рублей, прайс через дружественные юрисдикции — около 1,1 миллиона. Год назад это стоило 480 тысяч.

Второе. SCVMM (System Center Virtual Machine Manager) для управления кластером — отдельная лицензия, отдельная инфраструктура SQL Server, отдельная боль. Для офиса до 50 рабочих мест это перебор. Proxmox даёт кластерное управление через веб-интерфейс из коробки.

Дополнительно: Proxmox VE 8.x умеет всё, что я ждал от Hyper-V — Live Migration, HA, репликацию через ZFS, бэкапы через Proxmox Backup Server с дедупликацией, LXC-контейнеры для лёгких сервисов. И стоит подписка 110–1020 евро за сокет в год вместо сотен тысяч за Datacenter.

Что нужно сделать ДО окна миграции

Главное правило, которое я усвоил после нескольких ночных авралов: 80% работы делается заранее, в дневное время, без остановки сервиса. Если в окно вы лезете в неподготовленную систему — у вас будут проблемы.

Шаг 1: инвентаризация. Через PowerShell на Hyper-V-хосте я снимаю полную выгрузку:

# Список всех ВМ с базовыми параметрами
Get-VM | Select-Object Name, State, ProcessorCount, MemoryAssigned, `
  @{N='DiskGB';E={[math]::Round((Get-VHD ($_.HardDrives.Path)).FileSize/1GB,2)}}, `
  Generation, Version | Export-Csv C:\inventory.csv -NoTypeInformation

# Подробности по каждой ВМ — диски и сети
Get-VM | ForEach-Object {
  $vm = $_
  Get-VMHardDiskDrive -VM $vm | Select-Object @{N='VM';E={$vm.Name}}, Path, ControllerType
  Get-VMNetworkAdapter -VM $vm | Select-Object @{N='VM';E={$vm.Name}}, MacAddress, SwitchName, IPAddresses
}

Из этого отчёта я сразу понимаю: где старые ВМ Generation 1 (BIOS), где Generation 2 (UEFI), какие диски разрослись и нуждаются в чистке, какие MAC-адреса завязаны в DHCP/AD/лицензиях.

Шаг 2: установка VirtIO-драйверов в Windows-гостях. Это критично. Если поставить драйверы уже после миграции — Windows не загрузится. Скачиваю virtio-win-0.1.240.iso (или новее) с сайта Fedora Project, монтирую в работающую ВМ через Hyper-V Manager и ставлю драйверы для balloon, netkvm, viostor, vioscsi, vioserial, qemupciserial. Параллельно ставлю QEMU Guest Agent — он понадобится для корректного выключения и снятия снапшотов.

Шаг 3: удаление Integration Services Hyper-V. Они конфликтуют с VirtIO. На Windows: «Программы и компоненты» → Hyper-V Integration Services → Удалить. После перезагрузки Hyper-V продолжает работать, но через эмуляцию.

Шаг 4: для Linux-гостей. Убедитесь, что в initramfs есть virtio-модули. Для Ubuntu/Debian: `echo "virtio_blk virtio_pci virtio_net virtio_scsi" >> /etc/initramfs-tools/modules && update-initramfs -u`. Для CentOS/RHEL: `dracut --force --add-drivers "virtio_blk virtio_pci virtio_net virtio_scsi"`.

Шаг 5: подготовка Proxmox-хоста. На целевом Proxmox создаю «пустые» ВМ для всех будущих гостей — с правильным CPU, RAM и сетью, но без дисков. Это позволяет в окно миграции тратить время только на копирование данных, а не на щелчки в веб-интерфейсе.

Конвертация VHDX в qcow2: три рабочих способа

Hyper-V хранит диски в формате VHDX (новые) или VHD (старые). Proxmox с KVM работает с raw или qcow2. Конвертацию я делаю одним из трёх способов в зависимости от ситуации.

Способ 1: qemu-img напрямую с CIFS/SMB-шары

Самый простой случай — когда Proxmox-хост имеет сетевой доступ к папке с VHDX на Hyper-V-хосте. Монтирую SMB-шару и читаю файл напрямую:

# Монтируем шару Hyper-V с правами на чтение
mkdir -p /mnt/hyperv
mount -t cifs //hyperv-host/d$/VMs /mnt/hyperv \
  -o username=migrator,password=...,ro,vers=3.0

# Конвертация VHDX -> qcow2 с прогрессом
qemu-img convert -p -f vhdx -O qcow2 \
  /mnt/hyperv/srv-1c/Virtual\ Hard\ Disks/srv-1c.vhdx \
  /var/lib/vz/images/srv-1c-disk0.qcow2

# Проверка результата
qemu-img info /var/lib/vz/images/srv-1c-disk0.qcow2

Скорость на 10 Гбит/с — около 700–900 МБ/с, на 1 Гбит/с — около 100 МБ/с. Для диска 200 ГБ это 4 минуты или полчаса соответственно.

Способ 2: disk2vhd + WinSCP

Вариант на случай, если шару поднять нельзя. На работающей Windows-ВМ запускаю disk2vhd от Sysinternals (он умеет создавать VHDX «на горячую» через VSS), потом перекидываю файл через WinSCP на хранилище Proxmox и конвертирую там:

# На Proxmox после получения файла
qemu-img convert -p -f vhdx -O qcow2 \
  /var/lib/vz/dump/srv-fileserver.vhdx \
  /var/lib/vz/images/srv-fileserver-disk0.qcow2

Минус: это полностью «горячий» снимок, в нём может оказаться неконсистентное состояние БД. Для файлсервера ок, для 1С или MS SQL — лучше выключить ВМ.

Способ 3: virt-v2v для Linux-гостей

Когда мигрирую Linux, я почти всегда беру virt-v2v — он одной командой делает конвертацию + правит конфиги ОС:

# virt-v2v напрямую с экспортированной ВМ
virt-v2v -i disk /mnt/hyperv/srv-postgres.vhdx \
  -o local -of qcow2 \
  -os /var/lib/vz/images/

# Если ВМ на самом Hyper-V (через WinRM)
virt-v2v -i libvirtxml -o local -of qcow2 \
  -os /var/lib/vz/images/ \
  /tmp/srv-postgres.xml

virt-v2v сам подменит драйверы, перепишет fstab по UUID, регенерирует initramfs. Для CentOS, RHEL, Ubuntu, Debian, Alma и Rocky работает «из коробки».

Импорт диска в Proxmox: команда qm importdisk и нюансы

Когда qcow2 готов, дело за малым — прицепить его к ВМ. Алгоритм:

# 1. Создаём ВМ с нужными ресурсами
qm create 105 --name srv-1c --memory 32768 --cores 8 --sockets 1 \
  --cpu host --ostype win11 --machine q35 \
  --net0 virtio=00:15:5D:1C:42:7B,bridge=vmbr0,firewall=1 \
  --bios ovmf --efidisk0 local-lvm:0,format=raw

# 2. Импортируем сконвертированный диск в хранилище local-lvm
qm importdisk 105 /var/lib/vz/images/srv-1c-disk0.qcow2 local-lvm \
  --format qcow2

# 3. Цепляем диск как загрузочный через VirtIO-SCSI
qm set 105 --scsihw virtio-scsi-single \
  --scsi0 local-lvm:vm-105-disk-1,iothread=1,ssd=1,discard=on

# 4. Указываем порядок загрузки
qm set 105 --boot order=scsi0 --bootdisk scsi0

# 5. Включаем агента и balloon
qm set 105 --agent enabled=1 --balloon 16384

# 6. Запускаем
qm start 105

Несколько важных нюансов:

• MAC-адрес. Я всегда переношу MAC с Hyper-V — это сохраняет лицензии 1С, привязки в DHCP и в AD. Hyper-V использует префикс 00:15:5D, так что MAC легко узнаваем.
• Generation 2 → UEFI. Для ВМ из Hyper-V Gen2 обязательно `--bios ovmf` и EFI-диск, иначе Windows не стартанёт.
• VirtIO-SCSI single. Это рекомендованный контроллер для Proxmox 8.x — лучшая производительность, поддержка discard для тонких дисков.
• iothread=1. Выделяет отдельный поток для I/O — заметный прирост при нагрузке от 1С и SQL.
• discard=on. Освобождает место в LVM-thin/Ceph при удалении файлов внутри гостя. Без этого диск растёт и не сжимается.

Сценарий миграции с минимальным простоем

Для офиса с 12 ВМ я обычно укладываюсь в одно ночное окно с 22:00 пятницы до 07:00 субботы. Последовательность такая:

21:00. Финальная проверка готовности: VirtIO-драйверы поставлены везде, на Proxmox созданы пустые ВМ, шары смонтированы, Veeam-бэкап (или Wbadmin/Hyper-V Replica) сделан как страховка.

22:00. Останавливаем некритичные ВМ первой волны (тестовые, файлсерверы, RDS). По одной выключаем в Hyper-V, конвертируем VHDX, импортируем в Proxmox, проверяем загрузку, переключаем DNS-запись на новый IP (или назначаем тот же).

00:30. Контроллер домена. Тут есть нюанс: AD не любит, когда два DC с одинаковым именем «видят» друг друга. Я выключаю старый DC на Hyper-V, потом стартую новый на Proxmox. Если в домене один DC — заранее поднимаю второй на новом гипервизоре через dcpromo и метастазирую FSMO.

02:00. 1С и SQL. Самые большие диски (часто 200–500 ГБ), поэтому я начинаю эту часть пораньше. Перед выключением — обязательно полная выгрузка DT через Конфигуратор как страховка от любых проблем с переносом.

04:30. Терминальная ферма / RDS. После переноса проверяю профили пользователей, права, лицензирование RDS CAL.

06:00. Smoke-тесты. Через тестовые учётки прохожу основные сценарии: вход в 1С, открытие документа, печать, доступ к файловой шаре, отправка письма. Если всё ок — включаем мониторинг.

07:00. Окно закрыто. Старый Hyper-V-хост оставляю выключенным с целыми VHDX как «откат» на минимум 14 дней.

Простой для конечного пользователя — ноль, потому что в субботу утром люди не работают. Реальное время работы инженеров — 9 часов на 12 ВМ.

Когда нужна Live Migration без простоя

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

Hystax Acura Live Migration. Ставится агент на ВМ под Hyper-V, он непрерывно реплицирует диск в Proxmox-хост. Когда репликация догнала — окно переключения 30–90 секунд: остановка ВМ, синхронизация дельты, старт в Proxmox. Лицензия — около 300 долларов на одну ВМ.

Carbonite Migrate / DoubleTake. Аналогичная логика, чуть дороже (~500 долларов за ВМ), но лучше работает с СУБД и кластерами.

DRBD + Pacemaker. Бесплатный путь для Linux-гостей: настраиваем block-level репликацию через DRBD на новый Proxmox-хост, потом переключаем primary. Требует подготовки и понимания, но для офисов до 50 РМ я применял пару раз — работает.

Сравнение Proxmox с альтернативами после Hyper-V

На вопрос «куда мигрировать с Hyper-V?» я даю короткую матрицу:

Грабли, на которых я лично спотыкался

Грабля 1. Hyper-V Gen2 ВМ с включённым Secure Boot. После переноса в Proxmox с OVMF Secure Boot не дружит с готовым образом — нужно отключить через UEFI Setup или пересобрать ключи.

Грабля 2. Динамические VHDX, которые «на бумаге» 500 ГБ, а реально занимают 80 ГБ. qemu-img convert разворачивает диск на полный объём, если не указать `-O qcow2 -o preallocation=off`. На большом ZFS-пуле это съедает место мгновенно.

Грабля 3. Snapshots Hyper-V (точки восстановления). Перед миграцией обязательно слить через `Merge-VHD`. Иначе VHDX-файл — это только последняя дельта, без базового диска.

Грабля 4. Cluster Shared Volumes. Если ВМ на CSV в кластере Hyper-V — путь к VHDX выглядит как `C:\ClusterStorage\Volume1\...`, и просто скопировать файл нельзя при работающей ВМ. Нужен Live Migration на standalone-хост или экспорт через Hyper-V Manager.

Грабля 5. Лицензия Windows. После переноса Windows может «слететь» с активации (изменилось «железо»). Для KMS-лицензий — пересоединить с KMS-хостом, для retail/MAK — переактивировать. Я заранее предупреждаю клиента.

Грабля 6. Ресайз диска под уменьшение. Если в Hyper-V диск был 1 ТБ, а реально занят на 200 ГБ, в Proxmox можно усадить через `qm resize 105 scsi0 -300G` ТОЛЬКО после shrink файловой системы внутри гостя. Иначе теряешь данные. Для Windows — сначала «Сжать том» в diskmgmt.msc, для ext4 — `resize2fs` с предварительным fsck.

Что у клиента после миграции

Один из последних проектов — производственная компания на Дмитровском, 28 рабочих мест, 14 ВМ под Hyper-V (1С-кластер из 3 серверов, два контроллера домена, файлсервер 8 ТБ, несколько Linux-приложений, RDS-ферма на 18 пользователей). Перешли на кластер Proxmox VE 8.2 из двух нод HPE DL380 Gen11 с Ceph на 6 NVMe.

Цифры до и после:

За первый год экономия на лицензиях покрыла стоимость инженерной работы по миграции в 4 раза. Клиент доволен, мониторинг через Zabbix показывает 99,99% доступности гипервизора.

FAQ

Можно ли мигрировать кластер Hyper-V с CSV сразу в кластер Proxmox с Ceph?

Можно, но нужна правильная последовательность. Я делаю так: вывожу одну ноду из кластера Hyper-V, форматирую её под Proxmox, добавляю в Proxmox-кластер с Ceph. Затем по одной ВМ переношу через qemu-img + qm importdisk. После того как старый кластер Hyper-V «сжимается» до одной ноды — её тоже переформатирую и добавляю в Proxmox. Минимум двух нод Proxmox должно быть в любой момент времени для отказоустойчивости.

Что делать со снапшотами Hyper-V (checkpoints)?

Все снапшоты сливаем в основной диск ДО миграции командой Merge-VHD или через GUI Hyper-V Manager («Удалить контрольную точку → Применить»). Только после этого VHDX-файл содержит актуальное состояние, которое можно конвертировать.

Поддерживает ли Proxmox Generation 2 (UEFI) ВМ из Hyper-V?

Да, через машинный тип q35 + BIOS ovmf + отдельный EFI-диск. Параметры при создании ВМ: `--machine q35 --bios ovmf --efidisk0 local-lvm:0,format=raw`. Если в Windows был включён Secure Boot — после миграции его обычно нужно отключить через настройки UEFI Proxmox-хоста.

Как перенести Hyper-V Replica на Proxmox?

Hyper-V Replica хранит копии VHDX на втором хосте — их можно использовать как источник для конвертации, если основная ВМ работает. То есть выключаем реплику, конвертируем её VHDX в qcow2, импортируем в Proxmox. Когда новая ВМ в Proxmox запущена и проверена — переключаем основную нагрузку и старую ВМ выключаем. По сути, это сценарий миграции с почти нулевым окном.

Сколько стоит миграция «под ключ» с Hyper-V на Proxmox для офиса на 30 РМ?

В моих текущих прайсах (апрель 2026): аудит и план — 30–50 тысяч рублей, миграция 12–16 ВМ под ключ с настройкой кластера Proxmox + PBS — 180–280 тысяч рублей. Сюда не входит стоимость нового железа (если нужно) и месяца сопровождения после миграции. Для большинства клиентов это окупается за первый же год экономии на лицензиях Microsoft.

Что делать дальше

Если у вас сейчас крутится Hyper-V и вы думаете о переходе — начните с инвентаризации. Сделайте PowerShell-выгрузку всех ВМ, посчитайте лицензии, прикиньте бюджет на 3 года вперёд для обоих сценариев. Если получается, что Proxmox экономит больше 40% за горизонт — это уже сильный аргумент.

Я регулярно делаю бесплатный двухчасовой аудит для компаний до 50 рабочих мест в Москве: смотрим инфраструктуру, считаем ROI, обсуждаем риски. По итогу — конкретный план с цифрами и сроками.

Автор: Семёнов Е.С., технический директор ITfresh, 15+ лет опыта IT-аутсорсинга для бизнеса в Москве.