zVirt 4.0 и миграция с VMware vSphere: три кейса, честный разбор

zVirt 4.0 вышел на прошлой неделе, и мы встретили его не в вакууме: у нас параллельно идут три проекта миграции с VMware vSphere, и новая версия платформы пришлась прямо в разгар работ. Поэтому можем говорить не по документации, а по живому опыту.

Что изменилось в 4.0 по части миграции

Ключевое новшество релиза - переработанный модуль импорта виртуальных машин с vSphere. Раньше этот процесс требовал отдельной возни с OVF-экспортом, ручной правкой XML-дескрипторов и молитвами над форматами дисков. В 4.0 появился графический мастер миграции с прямым подключением к vCenter по API - указываешь адрес, credential, выбираешь ВМ из списка, указываешь целевой датасторе и пул ресурсов, жмёшь старт.

В теории - прозрачно. На практике - зависит от того, что именно мигрируешь.

Также в 4.0 расширена поддержка отечественных СХД: добавлены драйверы и проверенные конфигурации для ряда российских систем хранения с iSCSI и FC-подключением. Для объектов КИИ, которым нужна миграция с иностранного ПО, это важный момент: не нужно отдельно разбираться с тем, поедет ли конкретная СХД.

Три проекта - три разных опыта

Проект 1: промышленное предприятие, ~30 ВМ, ESXi 7.0

Здесь у нас было окно в выходные, поэтому выбрали холодную миграцию - гасим ВМ на vSphere, конвертируем, поднимаем на zVirt. Весь процесс прошёл чище, чем мы ожидали. Мастер миграции в 4.0 нормально подхватил инвентарь vCenter, конвертация дисков из VMDK в qcow2 шла по фоновым задачам без особых сюрпризов.

Что потребовало внимания:

• Сети. Маппинг Port Group из vSwitch в сети zVirt нужно проверять руками - автоматика предлагает варианты, но если в vSphere была нестандартная раскладка VLAN, можно легко промахнуться.
• Windows-машины. После конвертации несколько серверов на Windows Server 2019 потребовали ручной установки virtio-драйверов. Не все ставятся автоматически при первом старте, и ВМ могла зависнуть на загрузке с BSOD. Нужно монтировать ISO с драйверами через zVirt-консоль и ставить руками.
• Порядок загрузки. У пары машин слетел порядок загрузочных устройств. Поправили через настройки ВМ в интерфейсе - дело пяти минут, но неожиданно.

В итоге 28 из 30 машин поднялись без вмешательства. Две потребовали получаса ручной работы каждая.

Проект 2: финансовая организация, ~15 ВМ, ESXi 6.7, попытка горячей миграции

Вот здесь было интереснее - в плохом смысле. Клиент категорически не хотел окно с остановкой сервисов, поэтому пробовали горячую миграцию: ВМ продолжает работать на vSphere, zVirt 4.0 реплицирует диски в фоне через Storage vMotion-совместимый механизм, затем делается финальный срез и переключение.

Механизм в 4.0 существенно лучше, чем в 3.x - там эта функция была скорее экспериментальной. Но «лучше» не значит «без вопросов». Из 15 ВМ горячая миграция прошла чисто у 11. Остальные четыре:

• Две ВМ с высокой дисковой активностью (база MSSQL и 1С) дали ошибку синхронизации на финальном срезе - дельта накапливалась быстрее, чем успевала реплицироваться. Пришлось всё-таки делать кратковременное окно и переходить на холодный режим.
• Одна ВМ после переключения стартовала с corrupted filesystem на одном из дисков. Поднялась с fsck и работала нормально, но осадок остался.
• Одна просто завершила миграцию с ошибкой без внятного сообщения. Логи указывали на таймаут API vCenter. Повторили с нуля - прошло нормально.

Вывод по горячей миграции: работает, но нужна реалистичная оценка нагрузки на ВМ. Для ВМ с высоким disk I/O лучше всё-таки планировать короткое окно.

Проект 3: объект КИИ, 20 ВМ, vSphere 6.5, отечественная СХД

Этот проект идёт медленнее по причинам организационным, а не техническим. Но именно здесь улучшение поддержки СХД в zVirt 4.0 оказалось важным: СХД у клиента - отечественного производства, и в предыдущих версиях zVirt конфигурацию iSCSI приходилось поднимать в полуручном режиме. В 4.0 эта СХД появилась в списке проверенных конфигураций, и подключение прошло без экзотики.

Для managed-сопровождения объектов с требованиями ФСТЭК это принципиально - меньше времени на обходные решения, больше на собственно работу.

Честная оценка на текущий момент

zVirt 4.0 - заметный шаг вперёд по сравнению с предыдущими версиями, и это не реклама. Холодная миграция с vSphere работает надёжно и занимает разумное время. Горячая - работает, но требует осторожности и понимания нагрузки на конкретные ВМ. Не стоит её использовать «потому что можно», не оценив риски.

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

Если у вас стоит задача перехода с VMware - мы занимаемся именно такими проектами и можем помочь выстроить схему миграции под конкретные ограничения по доступности сервисов.