Четыре миграции с VMware за год: что накопилось по zVirt, Proxmox и oVirt

На прошлой неделе закрыли очередной проект - перенесли последние ВМ с VMware ESXi на zVirt у заказчика из производственного сектора. Это четвёртая миграция с VMware за последние двенадцать месяцев, которую мы провели в рамках managed-сопровождения. Три платформы назначения, разный масштаб, разные отрасли. Показалось уместным зафиксировать, что из этого опыта уже можно обобщить, а что по-прежнему требует индивидуального разбора.

Четыре проекта, три платформы

Если коротко о выборке:

• Проект 1 - zVirt. КИИ, производственный объект, требование ФСТЭК. Около шестидесяти ВМ, хостовая ОС - Astra Linux 2.8. Завершён в конце 2024-го, разбирали отдельно.
• Проект 2 - Proxmox VE. Коммерческая компания без требований КИИ, около сорока ВМ, смешанный парк Linux/Windows. Задача: уйти с VMware до истечения лицензий. Завершён в начале 2025-го.
• Проект 3 - oVirt. Инфраструктура разработки, около тридцати ВМ, требования к сертификации не жёсткие, но заказчик хотел именно oVirt как более знакомый стек для своих инженеров.
• Проект 4 - zVirt. Производственный сектор, КИИ, завершён на прошлой неделе. Около восьмидесяти ВМ, несколько хостов на отечественном железе.

Что реально занимает время

Самый частый вопрос на старте - сколько это займёт. Ответ, который мы даём сейчас, отличается от того, что мы говорили год назад.

Инвентаризация VMware-среды - первые 15-20% трудозатрат проекта. Каждый раз обнаруживается примерно одно и то же: ВМ без актуального владельца, снапшоты которые «временные» уже два года, datastores с неочевидной топологией, кастомные vSphere Distributed Switches которые никто не документировал. VMware vCenter хранит это всё, но не рассказывает по-человечески. Тратим время на добычу реальной картины, прежде чем думать о переносе.

Сетевая часть - отдельный проект внутри проекта. VMware DVS с port groups, VLAN-теггированием и политиками QoS - это не «просто настройки сети». На zVirt и oVirt аналог есть, но конфигурация другая. На Proxmox Linux bridges или OVS - снова другая. Три раза из четырёх именно переработка сетевой конфигурации уходила в критический путь, а не перенос ВМ.

Перенос ВМ как таковой - это обычно меньше половины работы. Сами ВМ переезжают предсказуемо: либо через virt-v2v, либо через промежуточный экспорт OVF, либо через snapshot + перенос дисков вручную. Каждый способ со своими нюансами, но это решаемые технические задачи. Больше времени уходит до и после.

Платформы: в чём реальная разница

После четырёх проектов у нас сложилось более чёткое понимание, для кого что.

zVirt - единственный разумный выбор для КИИ с требованием сертифицированного стека. Реестр ФСТЭК, поддержка Astra Linux 2.8 как хостовой ОС, документация на русском. Минус: вендор один, и иногда это ощущается - некоторые вопросы решаются только через их поддержку, обходных путей нет. Версия 4.1 добавила улучшенный планировщик, что реально ощутимо на кластерах с неравномерной нагрузкой.

Proxmox VE - самый низкий порог входа и самая живая open source экосистема. Для задач без жёстких требований регулятора это разумный выбор: хорошая документация, большое сообщество, работающий API. Но: коммерческая поддержка стоит денег, и если заказчик привык к vCenter-уровню удобства в управлении большим кластером - Proxmox потребует привыкания. Ещё один момент - на крупных инсталляциях (от пятидесяти хостов) начинает ощущаться, что Proxmox вырос из «умного homelab», а не из enterprise-продукта.

oVirt - интересный средний вариант для тех, кто хочет oVirt-механику без привязки к российскому вендору. Сам проект живёт, но медленнее чем хотелось бы: релизы выходят нечасто, некоторые баги висят долго. Для нашего третьего проекта выбор был обоснован тем, что команда заказчика уже знала oVirt по предыдущему опыту - это сократило обучение. В остальных случаях мы бы выбрали либо zVirt, либо Proxmox.

Что перестало удивлять

Год назад каждый из этих пунктов был неожиданностью хоть для кого-то в команде. Теперь - часть стандартного чеклиста.

• VMware Tools нужно менять на guest агентов целевой платформы. QEMU Guest Agent, open-vm-tools - разные вещи. Если не поменять до переноса или сразу после - теряете корректную остановку ВМ через гипервизор, balloon driver для памяти и часть метрик.
• Windows-ВМ требуют дополнительного шага с драйверами. VirtIO-драйверы для Windows - отдельный ISO, отдельная установка, отдельный тест. На Proxmox и zVirt/oVirt одинаково. Кто не готовит это заранее - теряет на этом шаге несколько часов.
• Снапшоты VMware не переносятся. virt-v2v берёт только текущее состояние диска. Перед миграцией нужно либо схлопнуть снапшоты, либо принять, что история теряется. Каждый раз этот разговор с заказчиком нужно проводить явно.
• Обратно дороги нет. Не технически - технически можно. Но организационно: как только VMware-лицензии не продлены и vCenter выключен, реальный откат стоит как новый проект. Поэтому тестирование перед финальным переключением - не опция.

Что по-прежнему требует индивидуального разбора

Было бы нечестно сделать вид, что у нас теперь универсальный скрипт на все случаи.

Хранилище. Каждый раз разное: NFS, iSCSI, Ceph, локальные диски. Поведение гипервизора при работе с СХД - особенно в части HA и fencing - нужно проверять на конкретной конфигурации. Sanlock на нестандартном железе, как мы уже разбирали, умеет преподносить сюрпризы.

Сложные ВМ. Базы данных под нагрузкой, ВМ с прямым доступом к железу (PCI passthrough), кластерные конфигурации типа Windows Server Failover Cluster поверх гипервизора - каждая из этих ситуаций требует отдельного плана переноса. Здесь шаблонные подходы не работают.

Команда заказчика. Если с VMware работали пять лет - новая платформа будет непривычной. Обучение и передача знаний занимают время, которое часто не закладывается в оценку проекта.

Где мы сейчас

Четвёртый проект закрыт. На горизонте - ещё несколько запросов на оценку. Рынок не замедляется: лицензии VMware дорожают или заканчиваются, регулятор требует отечественного стека для КИИ, и компании принимают решение не по желанию, а по необходимости. Это не всегда комфортная ситуация для заказчика, но она даёт нам достаточно данных, чтобы делать это быстрее и с меньшим количеством сюрпризов.