zVirt 3.1 в продакшне: первая крупная миграция с vSphere 7 на ~200 ВМ

Проект закрыли в конце января - первая по-настоящему крупная миграция с vSphere 7 на zVirt 3.1 в рамках управляемой инфраструктуры. Около двухсот виртуальных машин, production-среда, несколько критичных сервисов с требованием минимального простоя. Делимся тем, что реально зацепило по пути, а не глянцевым отчётом «миграция прошла успешно».

Контекст

Клиент - средний бизнес, собственный датацентр, железо российских вендоров плюс несколько стоек с HPE. vSphere 7 с весны 2022 официально не продлевается, продление поддержки VMware стало квестом. zVirt как отечественная платформа на базе oVirt был выбран ещё осенью, установка тестового кластера и пилот на нескольких ВМ прошли без сюрпризов. И вот начали катить в продакшн.

Где сломалось сразу

PVSCSI-драйверы. Это первый и главный камень. ВМ с контроллером PVSCSI (а у VMware это рекомендуемый вариант для нагруженных машин) при конвертации VMDK в QCOW2 стартуют, но не видят диск. Точнее, видят, но не загружаются - grub не находит root. Причина предсказуемая: PVSCSI - проприетарный драйвер VMware, в Linux-госте он зашит в initrd, а в KVM его нет. Решение - перед конвертацией переключить контроллер на LSI Logic SAS прямо в vSphere, перезагрузить ВМ там же, убедиться что гость стартанул с новым контроллером, и только потом конвертировать. Звучит просто, но когда таких машин несколько десятков - нужен скрипт.

Примерный алгоритм через PowerCLI:

# Переключение контроллера для списка ВМ перед миграцией
$vms = Get-Content vms_to_migrate.txt
foreach ($vmname in $vms) {
    $vm = Get-VM -Name $vmname
    $scsi = Get-ScsiController -VM $vm | Where-Object { $_.Type -eq "ParaVirtual" }
    if ($scsi) {
        Set-ScsiController -ScsiController $scsi -Type VirtualLsiLogicSAS
        Write-Host "$vmname: контроллер переключён"
    }
}

После этого - перезагрузка и проверка в vSphere перед тем, как трогать VMDK.

Скрипты и задания, завязанные на vCenter. У клиента была приличная коллекция PowerCLI-скриптов для резервного копирования, мониторинга и плановых задач через vCenter Tasks. Всё это перестало работать по очевидной причине. Часть задач пришлось переписывать под oVirt REST API, часть - переносить в Ansible. Неприятный момент в том, что полного реестра этих скриптов не существовало - они жили у разных администраторов в разных местах. Инвентаризация заняла больше времени, чем сама конвертация примерно трети машин.

Лицензирование гостевых Windows. Windows Server на ВМ в vSphere активируется через AVMA (Automatic VM Activation) - это механизм, завязанный на гипервизор VMware. После переезда на zVirt эта активация не работает. KVM AVMA не поддерживает вообще - это механизм Microsoft для Hyper-V, и у KVM нет аналогичных ключей активации. В итоге часть ВМ ушла в «нелицензионный» режим тихо, без явной ошибки - обнаружили только при проверке статуса. Лечится настройкой KMS-сервера или ручной переактивацией через корпоративные ключи, но нужно это планировать заранее и иметь реестр лицензий.

Что сработало нормально

Конвертация VMDK в QCOW2 через qemu-img надёжная и предсказуемая. Скорость зависит от размера и подсистемы хранения, но процесс стабильный. Thin-provisioned диски конвертируются корректно.

zVirt 3.1 с расширенной поддержкой железа - это реально заметно. На стойках с отечественными серверами проблем с драйверами не было вообще, тогда как на HPE пришлось разбираться с одной сетевой картой. В oVirt 4.x на той же HPE было хуже.

Встроенный Live Migration работает. Не так полированно как vMotion, но работает - мигрировали несколько ВМ без простоя в тестовом окне.

Итог на сейчас

Двести ВМ перенесены, продакшн работает. Но честно - «закрыть» этот проект можно только условно. Остаётся хвост: несколько специфичных Windows-гостей с проблемами активации, один кластерный сервис, который пока работает на старом vSphere-узле в изолированном VLAN, и не до конца переписанный пласт операционных скриптов.

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