Proxmox VE 7.3: как мы перевезли 400 ВМ с VMware vSphere и что пошло не так

Закрыли, пожалуй, самый объёмный проект по виртуализации за последнее время - миграция с VMware vSphere 7 на Proxmox VE 7.3, около четырёхсот виртуальных машин, production-кластер крупного промышленного предприятия. Прежде чем начать, скажем главное: Proxmox - это не zVirt и не oVirt. Это своё сообщество, своя документация, свои особенности. И некоторые из них мы обнаружили уже в процессе.

Почему Proxmox, а не что-то отечественное

Вопрос закономерный, особенно с учётом трендов последнего года. У клиента не было требований по реестру отечественного ПО и КИИ, поэтому выбор был чисто технический. Сравнивали три варианта: zVirt, oVirt напрямую и Proxmox VE. У zVirt свежий опыт миграции на ~200 ВМ у нас уже был - платформа рабочая, но ряд вещей там до сих пор требует патчей вручную. oVirt без коммерческой поддержки на таком объёме - риск.

Proxmox выиграл по трём причинам: живое upstream-сообщество, нормальная документация по HA, и главное - virt-v2v в Debian-стеке работает предсказуемее, чем в RHEL-производных. Это прагматика, не идеология.

Конвертер: virt-v2v против ручной конвертации

Спойлер: мы попробовали оба варианта и в итоге использовали оба - для разных типов машин.

virt-v2v - официальный инструмент для конвертации гостей из VMware в KVM. Умеет подключаться напрямую к vCenter через libvirt-VMX-транспорт, снимать образ, переустанавливать virtio-драйверы внутри гостя и отдавать готовый qcow2. Звучит как магия - и для Linux-гостей примерно так и работает. CentOS 7, Ubuntu 20.04, Debian 11 - конвертировались без вмешательства, virtio-net и virtio-blk подхватывались сами.

С Windows история сложнее. virt-v2v поддерживает Windows, но требует заранее установленных virtio-драйверов в гостевой ОС или их инжекции во время конвертации. Инжекция работает через ISO-образ virtio-win - нужно передать ключ --inject-virtio-win. На практике у части машин это работало чисто, у части - нет: драйвер сетевой карты после конвертации оказывался в состоянии «устройство не найдено». Причина выяснялась только после загрузки ВМ.

Ручная конвертация - для проблемных Windows и нескольких специфических Linux с нестандартными ядрами. Схема простая: экспорт VMDK через VMware, конвертация через qemu-img convert -f vmdk -O qcow2, затем загрузка в Proxmox и ручная установка virtio-драйверов внутри работающей ВМ. Медленнее, требует дополнительного простоя, зато полный контроль.

В итоге примерно две трети машин прошли через virt-v2v, остальные - ручной маршрут.

HA-кластер: где зарылись

Proxmox HA работает через Corosync + pve-ha-manager. В теории всё понятно: кворум, fencing, автоматический перезапуск ВМ при падении узла. На практике столкнулись с двумя моментами.

Первое - fencing. Без правильно настроенного STONITH HA-кластер не должен автоматически перезапускать ВМ на другом узле при потере связи с нодой - иначе рискуешь получить split-brain с двумя работающими копиями одной ВМ. В Proxmox fencing настраивается через агенты: IPMI, iDRAC, iLO или специфичные PDU. У клиента железо было смешанным - часть стоек с нормальным iDRAC, часть со старым IPMI без надёжной поддержки. Пришлось для части узлов ставить watchdog-based fencing, что работает, но менее надёжно.

Второе - размещение ВМ при восстановлении. По умолчанию pve-ha-manager при возврате упавшей ноды не перемещает ВМ обратно на неё автоматически - они остаются там, куда переехали. Это разумное поведение, но нужно об этом знать заранее, иначе через неделю обнаруживаешь, что все тяжёлые ВМ живут на одном узле.

Windows-лицензии: самая неприятная часть

Это знакомая история - писали про неё в контексте zVirt, здесь всё то же самое, только масштаб больше.

Windows Server на VMware активируется стандартным KMS или MAK-ключами - никаких специальных гипервизорных механизмов VMware для этого не использует. После переезда на KVM активация сбрасывается: Proxmox позволяет управлять SMBIOS виртуальных машин через конфиг (smbios1 в файле конфигурации ВМ), но этого недостаточно - нужен доступный KMS-сервер либо MAK-ключи.

У клиента был корпоративный KMS - часть машин переактивировалась сама после настройки маршрута до KMS-хоста. Часть ушла в режим «пробного периода» тихо, без ошибок в журнале. Обнаружили через slmgr /xpr на каждой Windows-ВМ - это вошло в обязательный чеклист финальной проверки.

Реестр лицензий был - и то хорошо. На проектах, где его нет, этот этап превращается в детективную историю.

Где сейчас

Четыреста машин на Proxmox VE 7.3, production работает. HA отрабатывает тесты по fencing нормально, Ceph для shared storage показывает стабильную производительность на текущей нагрузке.

Хвост остался небольшой: два специфичных приложения с Windows-гостями на кластерном диске, которые требуют разбора отдельно, и несколько PowerCLI-скриптов мониторинга, которые пока ещё переписываются под Proxmox API. Это работа управляемой инфраструктуры - не сдать проект и уйти, а держать до полного закрытия хвостов.

Основной вывод такой: virt-v2v реально ускоряет Linux-часть миграции, но на Windows рассчитывайте на ручную работу минимум для трети машин. И лицензии - планируйте отдельно, не в рамках конвертации.