Миграция между гипервизорами: KVM, Xen, VMware

MAATRIX

Смена гипервизора — это не то же самое, что перенос VM между двумя хостами Proxmox или между двумя ESXi. Там ниже уровня всё одинаковое, и перенос почти всегда сводится к копированию диска и импорту конфига. А вот перейти с VMware на KVM, или с Xen на KVM — значит поменять саму технологию виртуализации: другой формат диска, другие драйверы устройств внутри гостя, другая модель эмуляции сети и хранилища. Если просто скопировать файл диска и попытаться его запустить — в лучшем случае VM не увидит диск, в худшем Windows уйдёт в синий экран уже на этапе загрузки ядра. Разберём, что реально происходит при такой миграции и как её сделать без сюрпризов.

Почему прямой перенос диска не работает

Гипервизор — это не только планировщик CPU и распределение памяти. Это ещё и виртуальные устройства, которые видит гостевая ОС: виртуальный диск-контроллер, сетевая карта, видеокарта, шина PCI. VMware эмулирует одни устройства (и предлагает паравиртуализированные драйверы VMware Tools для ускорения ввода-вывода), KVM — другие (virtio), Xen — третьи (свои paravirtual drivers для PV/PVHVM режимов).

Файл виртуального диска VMware (VMDK) физически хранит те же биты данных — файловую систему, загрузчик, ядро. Но:

• Формат контейнера разный. VMDK, QCOW2 и форматы Xen — это разные способы упаковать блоки данных на уровне файла, со своей структурой заголовков, snapshot-цепочек и метаданных. KVM с VMDK напрямую обычно не работает (поддержка частичная и не универсальная), поэтому первый шаг почти всегда — конвертация в QCOW2 или RAW.
• Драйверы внутри гостя разные. Даже если формат диска решён, гостевая ОС внутри всё ещё "думает", что она работает на VMware-контроллере диска (например, LSI Logic или PVSCSI) и ищет соответствующий драйвер. На KVM этого контроллера физически нет — есть virtio-blk или virtio-scsi. Если в системе нет драйвера под новое устройство, диск может быть просто не виден загрузчику.

Из-за этих двух факторов миграция между гипервизорами — это всегда минимум два отдельных действия: конвертация формата и подготовка гостя к новым драйверам. Пропустить любое из них — значит получить VM, которая не грузится.

Форматы виртуальных дисков: зоопарк, с которым приходится жить

Коротко по основным форматам, с которыми встретитесь при миграции:

QCOW2 удобен на KVM тем, что поддерживает снапшоты "из коробки" и растёт по мере заполнения, но у этого есть обратная сторона на нагруженных базах данных — если интересно, почему на QCOW2 иногда заметно тормозят снапшоты, это отдельная тема про copy-on-write (разбор здесь). Для миграции же важно другое: раз формат целевого диска не совпадает с исходным, между ними должна быть конвертация — и это не файловая операция "переименовать расширение", а именно пересборка структуры образа.

Конвертация диска: где тут работает qemu-img

Экосистема KVM/QEMU включает утилиту для конвертации между форматами дисков — она умеет читать VMDK, VHD/VHDX и ряд других форматов и писать результат в QCOW2 или RAW. Концептуально команда выглядит так:

qemu-img convert -f vmdk -O qcow2 disk-from-vmware.vmdk disk-for-kvm.qcow2

Здесь -f — исходный формат, -O — целевой. Точный набор флагов, поддерживаемых опций сжатия и допустимых версий QCOW2 отличается между релизами пакета — не буду называть "точно верный" синтаксис для конкретной версии, потому что он реально меняется, и на боевой миграции стоит свериться с man qemu-img или qemu-img convert --help именно на той системе, где будете выполнять конвертацию.

Практические нюансы, которые чаще всего всплывают на этом шаге:

• Место на диске. Конвертация читает исходный образ целиком и пишет новый рядом — на время операции нужно as minimum столько же свободного места, сколько занимает исходный диск (а часто больше, если исходный был thin-provisioned и почти пустой).
• Время конвертации растёт линейно от размера диска и упирается в скорость чтения/записи хранилища — для дисков в сотни гигабайт это не секунды, а часто десятки минут.
• Xen — отдельная история. Если источник — Xen, готового единого пути "экспортировал → сконвертировал" может не быть вовсе: раздел на исходном Xen-хосте иногда лежит на LVM-томе без отдельного файла-образа, и первым шагом приходится сначала снять образ с тома (dd или аналог), и только потом конвертировать. Это на порядок муторнее, чем миграция с VMware, где VMDK — уже готовый файл.
• Проверяйте образ после конвертации — базовая проверка целостности контейнера (например, встроенная в ту же утилиту команда проверки) не гарантирует, что файловая система внутри цела, но хотя бы отсекает грубые ошибки самой конвертации.

Конвертация диска — необходимое, но недостаточное условие. Даже с идеально сконвертированным QCOW2 система внутри всё ещё может не загрузиться. Причина — в следующем разделе, и это самая частая причина провала подобных миграций.

Драйверы устройств — главная ловушка миграции

Вот та часть, которую легко упустить, если раньше вы мигрировали только "внутри одного гипервизора" (например, между узлами Proxmox), где такой проблемы попросту нет.

Гостевая ОС, которая раньше работала на VMware, во время установки получила драйверы под конкретные виртуальные устройства VMware: контроллер диска (обычно LSI Logic Parallel/SAS или PVSCSI), сетевую карту (VMXNET3), видеоадаптер. Эти драйверы устанавливаются либо из коробки ОС (базовый уровень совместимости), либо через VMware Tools — пакет, который докатывает более быстрые паравиртуализированные версии.

Когда вы переносите диск на KVM, виртуальная машина видит уже не LSI-контроллер и не VMXNET3, а virtio-blk/virtio-scsi для диска и virtio-net для сети (либо эмулируемые e1000/rtl8139, если virtio не настроен явно — но это медленный fallback, а не решение). Если в гостевой ОС нет драйвера под virtio-контроллер диска — загрузчик или ядро физически не могут прочитать диск, на котором находится сама система. Итог — либо ОС не стартует вовсе, либо стартует в режиме восстановления без доступа к нужным разделам.

Два рабочих сценария, чтобы этого избежать:

1. Подготовить гостя заранее, пока он ещё жив на старом гипервизоре. Установить драйверы virtio (для Windows — пакет virtio-win с драйверами блочных устройств и сети) в систему ДО миграции, пока она ещё загружается на VMware/Xen и вы можете спокойно поставить драйвер, перезагрузиться и убедиться, что всё в порядке. Это самый безопасный путь — вы тестируете совместимость драйверов, находясь ещё в рабочем окружении, с возможностью откатиться.
2. Переключиться на новые драйверы сразу после первого запуска на новом хосте, но с загрузочного recovery-образа. Если подготовить систему заранее не удалось (например, доступ к старой VM уже потерян), можно смонтировать диск на новом хосте под управлением recovery/live-образа, вручную подложить нужные драйверы в систему (для Windows это интеграция драйверов в offline-образ через dism или подобные инструменты, для Linux — правка initramfs) и только после этого пробовать штатную загрузку. Этот путь сложнее и требует больше ручной работы с внутренностями ОС.

Первый сценарий почти всегда предпочтительнее — потому что второй означает, что вы чините уже не загружающуюся систему, а это не то состояние, в котором хочется оказаться посреди рабочей миграции.

Windows-гости: почему это чаще всего кончается синим экраном

Для Windows проблема с драйверами проявляется особенно жёстко. Ядро Windows на этапе раннего старта опирается на строго определённый набор драйверов, загруженных в загрузочный ISO-образ boot-конфигурации (boot-critical drivers). Если контроллер диска, который видит система при старте, не совпадает с тем, под который загружен драйвер — Windows не может смонтировать системный раздел и падает в STOP-ошибку (тот самый синий экран) ещё до того, как успевает вывести что-то осмысленное на экран, кроме кода ошибки.

Именно поэтому смена гипервизора для Windows-VM без предварительной установки driver virtio почти гарантированно приводит к BSOD при первом запуске на KVM. Это не редкий крайний случай — это стандартное поведение, если пропустить подготовительный шаг.

Практическая рекомендация для Windows-гостей:

• Пока VM ещё работает на исходном гипервизоре, установите полный пакет virtio-драйверов (диск, сеть, при необходимости — балун памяти и последовательный порт) и сделайте так, чтобы Windows Boot Critical driver database знала о них — обычно это достигается штатной установкой пакета через инсталлятор, который сам регистрирует нужные записи, либо через dism /Add-Driver с флагом форсированной интеграции в offline-образ, если работаете с уже остановленным диском.
• Не удаляйте старые VMware-драйверы сразу — дайте системе поработать какое-то время с обоими наборами, убедитесь, что после следующей перезагрузки на исходном гипервизоре всё стабильно.
• Только после этого выполняйте конвертацию диска и запуск на KVM.
• Если система всё же не стартует — не спешите пересоздавать VM с нуля: часто помогает как раз второй сценарий из предыдущего раздела — загрузка с recovery/live-образа и ручная докатка драйвера в уже смонтированную офлайн-систему.

Linux-гости: обычно проще, но не автоматически

Для Linux ситуация мягче благодаря тому, что современные ядра (начиная с версий, которые уже много лет как стали стандартом в дистрибутивах) включают поддержку virtio "из коробки" — драйверы virtio-blk, virtio-scsi и virtio-net собраны как модули ядра или встроены статически в большинстве актуальных сборок. Это значит, что во многих случаях Linux-гость, перенесённый с VMware или Xen на KVM, просто увидит новый диск и сеть без дополнительных танцев.

Тем не менее "обычно проще" не значит "всегда без проблем":

• initramfs может не содержать нужный модуль, если система собиралась с расчётом только на конкретный набор устройств (актуально для минималистичных или сильно урезанных образов) — тогда после конвертации стоит пересобрать initramfs с явным включением virtio-модулей ещё до первой загрузки на новом хосте, если есть возможность смонтировать диск offline.
• UUID и имена дисковых устройств могут отличаться от того, что записано в /etc/fstab или в конфиге загрузчика — если fstab ссылается на /dev/sda1 напрямую, а не на UUID или label, после смены контроллера диска путь устройства может измениться, и система не смонтирует раздел, даже если ядро видит диск.
• Сетевые интерфейсы после смены гипервизора часто меняют имя (например, из-за смены MAC-адреса и правил udev/systemd-networkd для предсказуемых имён интерфейсов) — сетевой конфиг стоит перепроверить сразу после первого успешного запуска.

Ни один из этих пунктов не фатален так, как отсутствие boot-critical драйвера у Windows, но каждый способен превратить "загрузилось, но нет сети" в отдельное расследование на полчаса.

Практический план миграции и тестирование

Прежде чем переносить продакшн-систему, соберите последовательность в такую цепочку — и обязательно прогоните её целиком на тестовой VM, которую не жалко потерять:

1. Снять точный снапшот/бэкап исходной VM — миграция между гипервизорами необратима без отдельной резервной копии, откатить "туда же" зачастую невозможно.
2. Пока VM ещё работает на исходном гипервизоре — установить и проверить драйверы под целевую платформу (virtio для KVM).
3. Остановить VM корректно (не аварийно — от чистого выключения гостя внутри системы).
4. Сконвертировать диск в целевой формат, проверить целостность результата.
5. Собрать конфиг новой VM на целевом гипервизоре: те же объём диска, ядра/vCPU, память, но уже с виртуальными устройствами новой платформы (virtio-диск, virtio-сеть для KVM).
6. Первый запуск — с доступом к консоли (не только по сети), чтобы увидеть возможный BSOD или ошибку загрузки вживую, а не гадать по факту недоступности по SSH/RDP.
7. После успешной загрузки — проверить сеть, диски, службы, только потом переключать реальный трафик.

Отдельно стоит зафиксировать: тестируйте процесс на некритичной тестовой VM до того, как трогать прод. Это не формальность — это единственный способ заранее выявить, что именно пойдёт не так именно в вашем случае (какая версия драйвера нужна, как называется контроллер, что происходит с сетевыми именами) без риска для рабочей системы. Миграция между гипервизорами — тот редкий случай в администрировании, где "сначала на тесте, потом на проде" экономит не часы, а иногда сутки разбора почему прод не встаёт.

Если конечная цель — не просто сменить гипервизор, а вообще пересмотреть модель виртуализации (например, стоит ли использовать полноценный KVM или контейнеры), может быть полезно заранее сверить требования с материалом про выбор между KVM и LXC — миграция между гипервизорами часто становится поводом заодно пересмотреть, какая модель изоляции вообще нужна под конкретную нагрузку. А если параллельно меняется ещё и операционная система хоста (например, Windows Server на Linux), это отдельный пласт работы, который стоит планировать отдельно от смены гипервизора — см. миграцию с Windows Server на Linux.

Частые вопросы