Миграция виртуальных машин с 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
}

Один взгляд на этот отчёт — и мне сразу всё ясно: где тут ВМ первого поколения (те самые, с BIOS), а где уже Generation 2 (работающие на UEFI)? Какие диски разрослись так, что срочно требуют чистки? А главное, какие MAC-адреса критически завязаны в DHCP, Active Directory или, что ещё хуже, в лицензиях?

Шаг 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 МБ/с. На гигабите, конечно, поскромнее — около 100 МБ/с. Вот вам пример: для диска на 200 ГБ это означает 4 минуты или, соответственно, целых полчаса.

Способ 2: disk2vhd + WinSCP

Но что делать, если шару по каким-то причинам поднять ну никак не выходит? Не беда, у меня припасён другой вариант! Я просто запускаю утилиту disk2vhd от Sysinternals прямо на работающей Windows-ВМ. Кстати, она здорово умеет создавать 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 при удалении файлов внутри гостя. Без этого диск растёт и не сжимается.

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

Вот, например, возьмём обычный офис, где крутится дюжина виртуальных машин. Мы в ITFresh, как правило, спокойно укладываемся в одно ночное окно для такой миграции: начинаем примерно в 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 часов, чтобы перенести каждую из двенадцати виртуальных машин.

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

Представьте: ваша IT-система настолько критична, что даже микроскопическое окно обслуживания ночью просто невозможно. Например, у нашего клиента круглосуточный 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С-кластер на трёх серверах, два контроллера домена, ещё и файлсервер на 8 ТБ, несколько Linux-приложений, да вдобавок RDS-ферма на 18 пользователей. Мы взяли и перевели их на кластер Proxmox VE 8.2 — он теперь состоит из двух мощных нод HPE DL380 Gen11, которые работают с Ceph на 6 NVMe-дисках.

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

Знаете, что самое крутое? Уже за первый год они сэкономили на лицензиях Microsoft столько, что это в 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` или просто через графический интерфейс 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-выгрузку всех ваших ВМ, скрупулёзно посчитайте все лицензии, а затем прикиньте бюджет на ближайшие три года сразу по двум сценариям. И если вдруг окажется, что Proxmox экономит вам больше 40% за этот период, то, по-моему, это уже более чем весомый аргумент в его пользу, не находите?

Мы регулярно проводим бесплатный двухчасовой аудит для компаний в Москве с числом рабочих мест до 50. Смотрим вашу инфраструктуру, считаем потенциальный ROI, обязательно обсуждаем все риски. Итог? Вы получаете конкретный, чёткий план с цифрами и реальными сроками.

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