Мигрируем кластер из 80 ВМ с VMware vSphere 7 на zVirt: где прошло гладко, а где пришлось переустанавливать ОС

В июле мы писали про выбор между zVirt и oVirt в теории. Теперь есть что рассказать с практической стороны: один из клиентов, у которого лицензии на vSphere истекают в четвёртом квартале, дал добро на начало миграции прямо сейчас. Около 80 виртуальных машин, vSphere 7.0, два хоста ESXi, хранилище на iSCSI SAN. Целевая платформа - zVirt 3.3, который как раз вышел с обновлёнными инструментами импорта OVF/OVA.

Расскажем как есть: без прикрас, потому что прикрашивать особо нечего.

Что изменилось в zVirt 3.3 по части импорта

До версии 3.3 импорт VMware-образов в zVirt проходил через virt-v2v вручную или через не особо удобный скрипт на стороне хоста. В 3.3 Orion soft добавили нативную интеграцию прямо в движок: можно указать VMware vCenter или отдельный ESXi-хост, платформа сама подключается через VMware API, показывает список ВМ и тянет образы через встроенный механизм. Внутри всё равно работает virt-v2v, но это теперь деталь реализации, а не ручная работа.

Звучит хорошо. На практике - в целом да, но с нюансами.

Где конвертация прошла действительно бесшовно

Большая часть парка клиента - это Linux-машины на CentOS 7 и Ubuntu 20.04 с типичными ролями: веб-серверы, агенты мониторинга, вспомогательные сервисы. Примерно 50 ВМ из 80.

Для них процесс выглядел так: выбрали ВМ в интерфейсе zVirt, запустили импорт, подождали от 15 минут до часа в зависимости от размера диска, получили работающую ВМ. Сеть переназначили вручную - это ожидаемо, потому что сетевые профили VMware и zVirt разные. Virtio-драйверы zVirt ставит сам в процессе конвертации через virt-v2v, и это реально работает: ни одной ВМ с проблемами драйверов после импорта из этой группы не было.

Отдельно порадовали Ubuntu-машины с cloud-init: после импорта они поднялись чисто, hostname и сетевые настройки применились корректно.

Где пришлось повозиться

Windows Server 2016 и 2019 - отдельная история. Из примерно 20 Windows-машин бесшовно прошли около половины. У остальных после импорта были проблемы с virtio-драйверами: либо диск не монтировался, либо сеть не поднималась. Решение - ставить гостевые агенты virtio вручную ещё в VMware до экспорта, потом конвертировать. Это не открытие, это известная практика с virt-v2v, но zVirt 3.3 пока не делает этот шаг автоматически для Windows-гостей.

CentOS 6 - здесь мы знали, что будет сложно. Несколько старых машин с шестёркой: ядро слишком старое, virtio-драйверы официально не поддерживаются. Конвертация технически завершалась, но ВМ не стартовали. Приняли решение переустановить ОС: поставили Rocky Linux 8 (на базе RHEL 8), перенесли данные и конфиги вручную. Долго, но это скорее техдолг, который всё равно надо было закрывать.

Одна ВМ с кастомным ядром под специфическую задачу - тоже переустановка. Модифицированное ядро с патчами клиента через virt-v2v не конвертируется предсказуемо. Восстановили из резервной копии данных на чистом образе.

Как выглядел процесс по шагам

Примерная схема того, что мы делали:

1. Инвентаризация - прошли по всему парку, выделили три группы: Linux «стандартные», Windows, Linux «нестандартные» (старые ОС, кастомные ядра).
2. Подготовка Windows-машин - установка virtio ISO в VMware до экспорта, проверка что драйверы загружены.
3. Разворачивание zVirt - установка движка на отдельный хост, подключение iSCSI хранилища, настройка сети.
4. Импорт пачками - начали со стандартных Linux, потом Windows с подготовленными драйверами, нестандартные - в конце отдельным треком.
5. Проверка после импорта - сеть, DNS, сервисы. Для каждой ВМ отдельный чеклист.
6. Параллельная работа - vSphere при этом не трогали, ВМ продолжали работать там до момента переключения.

На VMware жили параллельно примерно три недели - пока не убедились, что все критичные ВМ в zVirt работают нормально под нагрузкой.

Что стоит знать заранее

Сетевые профили - заранее спланируйте маппинг сетей VMware на сети zVirt. В интерфейсе импорта это делается, но если сети много, лучше иметь таблицу.

Место под промежуточные образы - при импорте через OVF zVirt тянет образ целиком во временное хранилище, потом конвертирует. Для большой ВМ нужно место примерно в полтора-два раза больше размера диска.

Windows-машины - не надейтесь на автоматику. Либо готовьте virtio заранее, либо закладывайте время на ручное вмешательство после импорта.

CentOS 6 и другие EOL-системы - миграция - это повод закрыть вопрос с устаревшими ОС. Планируйте переустановку как отдельную задачу.

Где мы сейчас

Из 80 ВМ примерно 65 уже живут в zVirt и работают в продакшне. Оставшиеся 15 - это Windows-машины, которые ждут финального переключения на следующей неделе, и три ВМ, которые мы переустанавливаем. VMware работает параллельно, переключение по ВМ идёт поэтапно.

Общее впечатление от zVirt 3.3: инструменты импорта сделали процесс значительно аккуратнее, чем год назад. Для Linux-гостей - это реально рабочий путь без лишних телодвижений. Windows - требует подготовки. Старые ОС - это отдельный проект внутри проекта.

Если нужна помощь с планированием и проведением такой миграции, мы ведём её в рамках сопровождения инфраструктуры.