Как выбрать Proxmox или Hyper-V вместо VMware

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

Мой короткий вывод такой: Proxmox чаще выгоднее для смешанной инфраструктуры, ограниченного бюджета и команды, которая уверенно работает с Linux. Hyper-V чаще разумнее там, где почти все нагрузки работают на Windows Server, действуют лицензии Datacenter, а администраторы уже обслуживают Failover Clustering, Active Directory и PowerShell. Считать только цену гипервизора нельзя.

Решение начинается с границ проекта

Сначала зафиксируйте, что именно вы заменяете в VMware, потому что ESXi редко работает в одиночку. В счет миграции могут входить vCenter, vMotion, High Availability, Distributed Switch, vSAN, резервное копирование, репликация, мониторинг, шаблоны, роли доступа и автоматизация. Название нового гипервизора ничего не говорит о том, чем вы закроете весь этот набор.

Broadcom в своей базе знаний прямо описывает переход клиентов от бессрочных лицензий к подпискам VMware Cloud Foundation и VMware vSphere Foundation. Там же сказано, что бессрочная лицензия продолжает работать после окончания Support and Subscription: узлы ESXi, vCenter, виртуальные машины, операции питания, vMotion и снимки не отключаются. Но клиент теряет право получать обновления и открывать обращения в поддержку. Это важное различие. Окончание поддержки не создает аварийную остановку, зато оставляет рабочий кластер без нормального пути к исправлениям.

Поэтому не надо мигрировать в панике за неделю до продления. Сначала определите временное окно, в течение которого текущая версия VMware еще поддерживается вашим договором, резервным копированием, серверным оборудованием и гостевыми ОС. Этот срок дает возможность провести пилот, проверить восстановление и переносить нагрузки партиями.

Для трех узлов я начинаю проект с инвентаризации четырех вещей:

1. Количество ВМ, их ОС, виртуальные процессоры, память, фактически занятые данные и суточное изменение дисков.
2. Зависимости от VMware Tools, распределенных коммутаторов, vSAN, прямого подключения устройств, USB, GPU и общих VMDK.
3. Требования к RPO и RTO для каждой службы, а не одно пожелание «без простоя» для всего кластера.
4. Лицензии Windows Server, SQL Server, систем резервного копирования и мониторинга, включая условия переноса между физическими узлами.
5. Доступный простой и проверенный способ отката для каждой мигрируемой ВМ.

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

Инвентаризация должна отделять функцию платформы от привычки оператора. Например, создание шаблона есть в каждой системе, но шаблон может зависеть от cloud-init, Sysprep, пользовательских спецификаций vCenter, сетевых профилей и сценариев конфигурации. Запишите не название функции, а последовательность, которую выполняет команда: кто готовит образ, где хранятся секреты, как назначается адрес, как система попадает в мониторинг и сколько времени занимает готовность приложения. Тогда станет видно, какие части переносит гипервизор, а какие придется строить заново.

Еще одна граница проекта проходит по сети. Distributed Switch может хранить десятки VLAN, правила teaming, зеркалирование, ограничения скорости и специальные настройки для резервного копирования или хранения. Перенесите их в отдельную таблицу соответствий. Порт-группа VMware должна получить конкретный bridge и VLAN в Proxmox либо виртуальный коммутатор и VLAN в Hyper-V. Ошибка здесь проявляется как «приложение не работает», хотя диск и ОС перенесены правильно.

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

Три узла раскрывают разницу в хранении

В трехузловом кластере оба варианта могут перезапускать ВМ после отказа хоста, но делают это поверх разных стеков хранения. Proxmox обычно строят с внешним NFS или iSCSI, либо как гиперконвергентный кластер с Ceph. Hyper-V обычно опирается на SAN, SMB 3 или Storage Spaces Direct. Выбор хранения сильнее влияет на надежность и трудоемкость, чем внешний вид панели управления.

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

Ceph решает эту задачу, распределяя данные между узлами, но требует правильной сети, дисков и запаса ресурсов. Три узла для Ceph допустимы, однако это минимальная практичная конфигурация, в которой обслуживание одного сервера сразу уменьшает запас по отказам. Репликация с размером три хранит три копии объектов, поэтому полезная емкость получается заметно ниже сырой. Нельзя купить по одному большому диску на узел, сложить их объем и считать результат полезным пространством.

У Hyper-V роль Storage Spaces Direct объединяет локальные диски узлов в программный пул. Документация Microsoft Learn требует от двух до шестнадцати серверов и рекомендует одинаковую модель оборудования. Для малого кластера из двух или трех узлов нужна сеть с высокой пропускной способностью и низкой задержкой. Microsoft отдельно рекомендует Ethernet 10 Гбит/с или быстрее с RDMA для такой архитектуры.

На трех узлах Storage Spaces Direct поддерживает трехстороннее зеркалирование. Оно пишет три копии и дает около трети полезной емкости, зато переносит два одновременных аппаратных отказа в пределах описанной модели. Microsoft предупреждает, что диски, HBA, сетевые адаптеры, драйверы и прошивки должны соответствовать требованиям, а конфигурация кластера должна пройти Test-Cluster. Пропускать эту проверку ради «обычных серверов» нельзя: неподдерживаемая связка чаще ломается во время обновления, когда один узел уже выведен из работы.

При внешнем общем хранилище Proxmox подключает NFS, iSCSI и другие поддерживаемые типы, а Hyper-V обычно использует SAN или SMB 3. При локальных дисках Proxmox предлагает Ceph либо асинхронную репликацию ZFS с ограничениями, а Microsoft предлагает Storage Spaces Direct в Datacenter. Кворум Proxmox опирается на Corosync, кворум Microsoft на Failover Clustering и выбранный witness. Главный риск Proxmox состоит в недооценке сети и поведения Ceph при деградации. Главный риск Hyper-V состоит в неподходящем оборудовании, прошивках и неверном расчете лицензии Datacenter.

Не смешивайте синхронное общее хранилище и асинхронную репликацию. При Ceph или Storage Spaces Direct подтвержденная запись распределяется согласно политике отказоустойчивости до ответа приложению. При ZFS replication в Proxmox копия на другом узле отстает на интервал задания. После внезапной потери исходного узла HA может запустить только состояние последней успешной репликации, а незаписанный интервал станет потерей данных. Такая схема подходит не каждой базе и должна быть отражена в RPO.

Сеть хранения нельзя оставлять на том же единственном коммутаторе и паре портов, которые обслуживают пользователей и управление. Нужны рассчитанная пропускная способность, отказ одного пути, согласованный MTU и наблюдение за потерями пакетов. Jumbo frames сами по себе не ускоряют плохо спроектированную сеть. Несовпадающий MTU на одном участке дает редкие зависания и повторные передачи, которые особенно тяжело искать во время ребалансировки.

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

Если у вас уже есть исправная SAN с поддержкой производителя, не надо автоматически заменять ее гиперконвергентным хранением. Использование существующего массива снижает объем изменений и в Proxmox, и в Hyper-V. Если SAN тоже пора менять, сравнивайте две полные архитектуры, включая коммутаторы, оптику, HBA, запасные диски и резервное копирование.

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

Базовые функции кластера есть у обоих

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

В Proxmox одна веб-панель управляет узлами, хранилищами, виртуальными машинами KVM и контейнерами LXC. Кластер работает по модели multi-master: для обычного управления не нужен отдельный аналог vCenter. Live migration переносит работающую ВМ между узлами, если процессор и хранилище совместимы с выбранным режимом. HA отслеживает ресурсы и перезапускает ВМ на доступном узле после отказа.

LXC не надо считать заменой виртуальной машине. Контейнер использует ядро хоста и подходит для Linux-нагрузок, которым не нужна отдельная ОС и жесткая граница виртуального оборудования. Windows в LXC не запустится. Переносить обычную ВМ в контейнер только ради плотности размещения стоит как отдельный проект приложения, а не как часть механической миграции гипервизора.

Hyper-V дает live migration и storage migration даже без отказоустойчивого кластера, но автоматический перезапуск после отказа требует Failover Clustering и доступного другим узлам хранилища. Для доменной среды Microsoft хорошо интегрирует аутентификацию, делегирование Kerberos, групповые политики и PowerShell. System Center Virtual Machine Manager добавляет управление большим парком, библиотеку образов и автоматизацию, но это отдельный продукт с отдельной стоимостью и обслуживанием.

Windows Server 2025 также поддерживает кластер Hyper-V в рабочей группе и live migration без Active Directory. Это полезная новая возможность, но она не делает настройку проще доменного варианта: на узлах нужны согласованные локальные учетные записи, DNS, WinRM и доверенные узлы. Если в организации уже есть надежный домен, искусственно убирать из него кластер обычно нет смысла.

Резервное копирование остается отдельной системой. Встроенная задача backup в Proxmox умеет создавать согласованные архивы ВМ, а Proxmox Backup Server добавляет дедупликацию, инкрементальные передачи и проверку данных. Hyper-V использует VSS и интерфейсы, которые поддерживают многие корпоративные продукты резервного копирования. В обоих случаях наличие кнопки backup еще не доказывает восстановление. Нужны изолированная копия, политика хранения и регулярный тест запуска восстановленной ВМ.

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

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

Стоимость считают по узлам, сокетам и гостевым ОС

Proxmox обычно дешевле по лицензии платформы, но Hyper-V может оказаться экономичнее для плотного парка Windows Server, если права Datacenter уже нужны для гостевых систем. Сравнивать «бесплатный Proxmox» с ценой Windows Server неправильно: Windows-гости требуют лицензий независимо от выбранного гипервизора.

Все функции Proxmox VE, включая HA, кластер и live migration, доступны без платной подписки. Подписка дает доступ к Enterprise Repository и технической поддержке. Публичный прайс Proxmox считает каждый занятый физический сокет на каждом узле, а все узлы кластера должны иметь одинаковый уровень подписки. Указанные производителем цены составляют 120 евро в год за сокет для Community, 370 для Basic, 550 для Standard и 1100 для Premium без налогов. Только Basic, Standard и Premium включают обращения в поддержку, причем время реакции и число обращений различаются.

Для трех одно-сокетных узлов формула проста:

Proxmox VE в год = 3 узла × 1 занятый сокет × тариф
Standard: 3 × 1 × €550 = €1650 без налогов
Premium: 3 × 1 × €1100 = €3300 без налогов

Если в каждом сервере стоят два процессора, сумма удваивается. Отдельно посчитайте подписку Proxmox Backup Server, поддержку интегратора, оборудование резервного хранилища и рабочее время команды. Сам продукт можно использовать без подписки, но производственный кластер на репозитории no-subscription ради экономии небольшой суммы я не рекомендую. Обновления там проходят меньше проверок, а в момент серьезного сбоя вам понадобится не форум, а понятная линия эскалации.

Hyper-V входит в Windows Server, но бесплатного отдельного Hyper-V Server для актуального нового развертывания нет. Windows Server 2025 лицензируется по физическим ядрам. Standard дает право на две виртуальные машины Windows Server плюс хост Hyper-V после полного лицензирования ядер сервера. Datacenter дает право на неограниченное число таких гостевых экземпляров на полностью лицензированном хосте и открывает Storage Spaces Direct.

Microsoft публикует ориентировочную цену 1176 долларов за Standard и 6771 доллар за Datacenter, но фактическая цена зависит от канала, числа ядер, договора и региона. Эти значения нельзя просто умножить на три, не проверив комплект лицензии и конфигурацию процессоров. Для кластера надо лицензировать каждый физический узел так, чтобы любая Windows-ВМ имела право работать на нем после миграции или автоматического перезапуска. Права доступа CAL, SQL Server и другое серверное ПО считают отдельно.

Standard выглядит дешево, пока ВМ мало. После полного покрытия физических ядер он дает права на два гостевых экземпляра Windows Server. Для следующих двух экземпляров те же физические ядра лицензируют еще раз. В кластере нельзя считать только обычное размещение, например четыре ВМ на каждом узле. После отказа один сервер может принять больше гостевых систем, поэтому лицензионный проект должен учитывать разрешенное перемещение и условия конкретного договора. Получите письменный расчет от поставщика лицензий и сохраните его вместе со схемой размещения.

Datacenter дороже одной лицензии Standard, зато снимает ограничение по числу гостевых Windows Server на полностью лицензированном узле и включает Storage Spaces Direct. Это не означает, что любой трехузловой Hyper-V автоматически требует Datacenter. При внешней SAN и небольшом числе Windows-гостей Standard может быть достаточным. При десятках ВМ и локальном программном хранилище Datacenter обычно становится естественной базой расчета.

Гостевые Linux-системы не потребляют права на виртуальные экземпляры Windows Server, но физические ядра хоста все равно покрываются выбранной редакцией, если Hyper-V работает на Windows Server. На Proxmox лицензия хоста Microsoft не нужна, зато каждая гостевая Windows должна иметь собственное законное основание. Это и есть различие, которое часто размывают фразой «Hyper-V бесплатный». Роль гипервизора входит в ОС, а права на ОС и виртуализацию остаются платными.

Стоимость поддержки тоже сравнивают на одинаковом уровне. Premium у Proxmox обещает первую реакцию на критическое обращение в течение двух часов в рабочий день по австрийскому календарю и часовому поясу. Это не круглосуточное устранение аварии. Microsoft, OEM-производитель сервера, поставщик хранилища и локальный интегратор имеют собственные границы ответственности. Запишите, кто принимает звонок ночью в Казахстане, кто собирает диагностику и кто имеет право подключиться к системе.

Полезная модель TCO на три года выглядит так:

TCO = лицензии и подписки
    + серверы, сеть и хранилище
    + резервное копирование
    + проект миграции
    + обучение и регламенты
    + плановые обновления
    + ожидаемая стоимость простоя

Не подставляйте в последнюю строку выдуманную «среднюю цену часа». Возьмите две реальные службы, спросите владельцев об ущербе от четырех часов недоступности и используйте эти значения для выбора уровня поддержки. Так бюджет отражает ваш риск, а не красивую таблицу поставщика.

Команда должна знать нижний слой

Знакомая панель ускоряет первые операции, но квалификация администратора проверяется при деградации хранения, потере кворума и неудачном обновлении. Proxmox требует уверенного Linux-администратора. Hyper-V требует уверенного Windows-администратора, который понимает Failover Clustering, хранилище, сеть и лицензирование, а не только умеет создавать ВМ в Hyper-V Manager.

Для Proxmox нужны практические навыки Debian, systemd, сетевых мостов Linux, VLAN, LVM или ZFS, QEMU/KVM, Corosync и выбранного хранилища. Если применяется Ceph, администратор должен читать состояние PG, понимать recovery, backfill, OSD, MON и влияние заполнения пула. Зеленый значок в панели не заменяет понимание, почему Ceph замедлился после отказа диска.

Для Hyper-V нужны Windows Server, PowerShell, Failover Cluster Manager, Cluster Shared Volumes, SMB, MPIO или Storage Spaces Direct, VSS, Active Directory и Kerberos. В Microsoft Learn разбор сбоев live migration перечисляет несовпадение процессоров, версий конфигурации ВМ, виртуальных коммутаторов, разрешений и настроек делегирования. Это хороший контраргумент фразе «Hyper-V проще, потому что он Windows». Он проще только для команды, которая уже умеет диагностировать этот стек.

Оцените команду не по сертификатам, а по четырем заданиям в лаборатории:

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

Если сотрудники не выполняют два задания из четырех без подсказки, заложите обучение и сопровождение интегратора. Это не аргумент против платформы. Это честная стоимость ее эксплуатации. Один сильный специалист без дежурной замены тоже не считается командой, особенно если заявлена круглосуточная доступность.

Документация должна описывать не счастливый путь, а признаки конкретных отказов. Для Proxmox сохраните команды проверки кворума, состояния Ceph, заданий HA, репликации и резервных копий. Для Hyper-V сохраните команды и отчеты проверки кластера, CSV, Storage Spaces Direct, live migration и VSS. У каждой проверки должен быть пример нормального результата и условие эскалации. Иначе дежурный увидит сотни строк, но не поймет, какая из них требует остановки миграций.

Обновления дают хороший тест зрелости. Proxmox обновляет Debian, ядро, QEMU, Corosync и при необходимости Ceph. Hyper-V обновляет Windows Server, драйверы, прошивки и функциональный уровень кластера. В обоих случаях правильный процесс начинается с проверки backup, перевода одного узла в обслуживание, переноса нагрузок и наблюдения за хранилищем. Массовый перезапуск трех узлов по одному сценарию превращает кластер в три одинаковые точки отказа.

Перенос в Proxmox короче, но не автоматический

Proxmox дает прямой импорт из VMware и понятный ручной путь через OVF или VMDK, однако после конвертации все равно надо исправить виртуальное оборудование и проверить гостевую ОС. Импорт диска не переносит правила Distributed Switch, политики vSAN, задания резервного копирования, теги, права и мониторинг.

Руководство Proxmox VE описывает Import Wizard, который появился в версии 8.2, и ручную команду qm importovf. Для выключенной ВМ базовая последовательность выглядит так:

qm importovf 100 app01.ovf ceph-vm
qm config 100

Типичный вывод последней команды должен содержать выбранные параметры, например:

boot: order=scsi0
cores: 4
memory: 8192
name: app01
net0: virtio=BC:24:11:7A:20:10,bridge=vmbr0,tag=120
scsi0: ceph-vm:vm-100-disk-0,size=120G
scsihw: virtio-scsi-single

Это не готовый рецепт для любой ВМ. Идентификатор, хранилище, тип процессора, мост, VLAN и контроллер надо выбрать по проекту. Ценность последовательности в другом: она создает проверяемый объект, конфигурацию которого можно сохранить в протокол миграции и сравнить с планом.

До экспорта остановите прикладные задания и зафиксируйте владельца переключения. Для обычного сервера выключение через гостевую ОС дает согласованное состояние файловой системы. Для базы данных нужен штатный останов службы или резервный механизм приложения. Принудительное выключение в vCenter только ради экономии пяти минут может добавить часы восстановления журнала на новой платформе.

Сетевая карта требует такой же аккуратности. Новая MAC-адресация может создать скрытый старый адаптер Windows, оставить прежний статический IP на отсутствующем устройстве или поменять имя интерфейса Linux. Запишите IP, маску, шлюз, DNS, VLAN, маршруты и MTU до выключения. После запуска проверяйте соединение с точки зрения клиента и зависимых систем, а не одним ping с консоли.

Windows часто не загружается, если сразу заменить знакомый ей контроллер диска на VirtIO. Безопаснее сначала импортировать диск на SATA или IDE, запустить систему, удалить VMware Tools, установить актуальные гостевые драйверы VirtIO, добавить тестовый диск на новом контроллере и убедиться, что драйвер загрузился. После этого системный диск можно перевести на VirtIO SCSI и проверить загрузку еще раз. Для старых ОС возможны отдельные ограничения драйверов и режима BIOS или UEFI.

Linux обычно переносится проще, но ловушки остаются. Имя сетевого интерфейса может измениться, старый initramfs может не содержать нужный модуль, а /etc/fstab может ссылаться на устройство вместо UUID. Перед переключением сохраните сетевую конфигурацию, проверьте загрузчик, установите qemu-guest-agent и убедитесь, что приложение слушает правильный адрес после смены виртуальной сетевой карты.

Снимки VMware нужно консолидировать до экспорта. Цепочка дельта-дисков увеличивает время, место и риск ошибки. ВМ с физическим RDM, общей шиной для гостевого кластера, PCI passthrough или виртуальным TPM требует отдельного плана. Такие нагрузки не надо прятать в общую партию «остальные серверы».

Secure Boot и виртуальный TPM требуют проверки до переноса. Ключи, которые защищают диск BitLocker, могут зависеть от виртуального оборудования. Сохраните recovery key и подтвердите, что он работает, до первого запуска копии. Если система использует шифрование на уровне приложения или ОС, обычная конвертация диска не гарантирует автоматическую загрузку.

Откат должен быть технически возможен и организационно разрешен. После успешной проверки выключенную VMware VM не удаляют сразу. Ее сетевые карты оставляют отключенными, задают срок хранения и защищают от случайного запуска одновременно с новой копией. Два сервера с одним именем, IP и идентификатором приложения создают более неприятный инцидент, чем неудачная миграция.

Перенос в Hyper-V требует отдельного конвейера

Hyper-V хорошо принимает VHD и VHDX, но исходные диски VMware обычно имеют формат VMDK, поэтому проекту нужен поддерживаемый способ конвертации. Microsoft предлагает несколько путей, и они сильно различаются по зрелости и стоимости.

System Center Virtual Machine Manager 2025 умеет преобразовывать VMware VM в среде VMM и поддерживает EFI-нагрузки. Это подходящий путь, если System Center уже используется и команда умеет его обслуживать. Покупать и внедрять VMM только ради нескольких десятков ВМ может быть дороже самой миграции.

В Windows Admin Center есть расширение VM Conversion для переноса VMware в Hyper-V. Оно синхронизирует диски, выполняет предварительные проверки, делает дельта-репликацию, выключает исходную ВМ, переносит последнюю дельту и импортирует машину. Документация Microsoft помечает расширение как Preview и прямо предупреждает, что предварительный продукт может существенно измениться, а Microsoft не обязана предоставлять поддержку. Для лаборатории это полезный вариант. Делать его единственным производственным путем без испытания и запасного метода я бы не стал.

Ручной путь состоит из выключения ВМ, консолидации снимков, конвертации VMDK в VHDX поддерживаемым инструментом, создания Generation 1 или Generation 2 VM, подключения дисков, настройки виртуального коммутатора и исправления загрузки. Поколение выбирают по прошивке и разметке исходной системы. Неверный выбор между BIOS и UEFI дает диск с исправными данными, который не загружается.

Generation 1 использует традиционный BIOS и обычно загружается с IDE-диска. Generation 2 использует UEFI, Secure Boot и виртуальный SCSI. Между поколениями нет простой кнопки переключения существующей ВМ. Проверьте тип прошивки, схему разделов и поддержку гостевой ОС до конвертации. Угададывание по возрасту сервера дает ненужные попытки восстановления загрузчика.

Windows Admin Center VM Conversion интересен дельта-синхронизацией, потому что основная масса данных переносится до выключения источника. Но статус Preview меняет отношение к риску. Сохраните поддерживаемый холодный путь, измерьте полный повтор операции и убедитесь, что исходная ВМ остается пригодной к запуску после неудачной финальной дельты. Предварительная проверка инструмента не заменяет прикладную проверку владельца сервиса.

Перед первым стартом Windows удалите или отключите компоненты VMware, которые могут конфликтовать с новой сетевой картой и службами. После запуска проверьте Integration Services, IP-конфигурацию, активацию, время, VSS writers и журнал событий. Для Linux проверьте поддержку Hyper-V в ядре, имена интерфейсов, демон времени и корректное завершение работы через гипервизор.

У Hyper-V есть преимущество для Windows-нагрузок: драйверы и службы интеграции входят в современные версии Windows Server, а автоматическая активация AVMA работает для подходящих гостевых версий на активированном хосте Datacenter. Но это не отменяет лицензирование каждого узла кластера. Microsoft отдельно указывает, что в failover-кластере каждый Hyper-V host должен быть активирован, иначе ВМ после перемещения может потерять корректное состояние активации.

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

Пилот доказывает восстановление, а не запуск

Успешный вход в гостевую ОС после импорта подтверждает только то, что диск загрузился. Пилот считается законченным, когда команда показала отказ узла, восстановление из резервной копии, плановое обновление и возврат приложения к согласованным RPO и RTO.

Я использую один и тот же приемочный сценарий для обеих платформ:

1. Развернуть три узла с финальными моделями сети и хранения, затем выполнить штатную проверку кластера.
2. Перенести репрезентативные ВМ, записать длительность и проверить приложение со стороны пользователя.
3. Запустить резервное копирование, удалить тестовую ВМ и восстановить ее под новым именем в изолированную сеть.
4. Переместить работающую ВМ между каждым сочетанием узлов и замерить потерю пакетов и паузу приложения.
5. Отключить один узел без корректного завершения, проверить кворум, автоматический запуск и состояние хранилища, затем вернуть узел.

После сценария должны остаться журналы, измерения и список отклонений. Формулировка «вроде переключилось» не проходит приемку. Для базы данных проверьте транзакционную целостность, для файловой службы права и открытие файлов, для доменного контроллера репликацию, для приложения фоновые задания и интеграции.

Отказ сети тестируют отдельно от отказа питания. Отключите один путь хранения, один uplink трафика ВМ и один интерфейс управления. Убедитесь, что переключение не создает петлю, смену MTU или потерю доступа к witness. Полное выключение узла часто скрывает ошибки multipath, потому что кластер просто переносит ВМ, не проверяя деградированный путь на живом сервере.

Заранее задайте пороги. Например, «приложение доступно через 10 минут» имеет смысл только вместе с методом измерения и ответственным наблюдателем. Не путайте время перезапуска ВМ со временем восстановления службы: гостевая ОС может подняться за минуту, а база будет делать recovery еще двадцать.

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

Критерий перехода должен быть двоичным. Например: все пять типов ВМ перенесены, восстановление уложилось в RTO, потеря узла не нарушила RPO, обновление одного сервера завершилось без аварии, дежурная смена выполнила регламент. Оценка интерфейса и субъективное «команде понравилось» можно учитывать, но она не заменяет эти доказательства.

Выбор зависит от вашей уже оплаченной сложности

Для типичного трехузлового кластера Proxmox стоит выбрать, если преобладают Linux или смешанные нагрузки, нет большого пакета лицензий Windows Server Datacenter, команда знает Linux, а организация готова стандартизировать Ceph либо использовать существующее общее хранилище. Он дает компактный стек, прозрачную цену поддержки и прямой импорт VMware. Цена этой свободы состоит в ответственности за Linux, Ceph и гостевые драйверы.

Hyper-V стоит выбрать, если большинство ВМ работает на Windows Server, права Datacenter уже куплены или обоснованы плотностью виртуализации, команда уверенно поддерживает Microsoft-стек, а оборудование подходит для проверенной конфигурации Failover Clustering и Storage Spaces Direct. Он уменьшает число незнакомых технологий для Windows-команды. Цена такой привычности состоит в лицензировании ядер, CAL, возможном System Center и более тяжелом конвейере VMDK в VHDX.

Если обе команды начинаются с нуля, Proxmox обычно дает более низкий порог стоимости, но не более низкий порог ответственности. Если у вас шесть Windows-ВМ и два Linux-сервера на каждом узле, посчитайте Standard и Datacenter с правами миграции, а затем сравните с Proxmox плюс отдельные лицензии Windows-гостей. Если у вас десятки Windows-ВМ на узел и уже действует Datacenter, Hyper-V может выиграть до начала технического сравнения.

Есть и третий честный результат: не выбирать одну платформу для всех нагрузок. Несколько систем с жесткой сертификацией VMware можно оставить на поддерживаемой версии до их замены, а новые и переносимые ВМ разместить на выбранном кластере. Временная смешанная среда повышает нагрузку на мониторинг и backup, поэтому ей нужен срок завершения. Но она безопаснее, чем принудительный перенос неподдерживаемого приложения ради красивой даты закрытия проекта.

Не принимайте решение по демонстрации интерфейса. Попросите две архитектуры с одной спецификацией серверов, одинаковыми RPO и RTO, одинаковым сроком поддержки и одним набором тестов. Затем сравните трехлетний TCO и часы, которые ваша команда потратила на пилот. Разница в этих двух числах обычно честнее любой матрицы функций.

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