09 марта 2023 Время чтения: 15 минут

Миграция с VMware на VMmanager

Олег Абанкин

Олег Абанкин

Менеджер по продукту VMmanager

ISPSystem

Как перенести виртуальные машины с VMware ESXi на платформу виртуализации VMmanager? В этой статье мы сделаем обзор наиболее распространенных в интернете методов миграции, а также приведем последовательность конкретных шагов миграции для нескольких типовых сценариев, покажем методы настройки устройств ввода-вывода для QEMU-KVM.

Особенности миграции с VMware

Для лучшего понимания дальнейших шагов хочется начать статью с описания некоторых особенностей миграции, с которыми приходится сталкиваться.

Для любой миграции виртуальных машин применяется стандартный подход — конвертация диска из одного формата в другой. Формат дисков у VMware — это .vmdk. Для QEMU-KVM, который использует VMmanager, формат диска — .qcow2 или raw.

Существует утилита qemu-img, которую развивает команда проекта QEMU. Она уже установлена на вашей системе, если вы используете связку QEMU-KVM-libvirt. Qemu-img позволяет выполнить конвертацию дисков виртуальных машин между различными форматами. В частности, можно конвертировать из .vmdk в .qcow2 или из .qcow2 в raw. Более подробно про утилиту можно почитать в официальной документации по ссылке.

Может показаться, что достаточно просто сконвертировать диски и все будет работать, но, к сожалению, все немного сложнее. Такая конвертация для виртуальной машины будет аналогична ситуации, с которой сталкивается операционная система ноутбука, когда вы переставили диск из одного компьютера в другой.

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

На VMware тип загрузчика можно посмотреть в настройках виртуальной машины. В примере ниже используется BIOS, но по умолчанию в VMware используется UEFI.

Настройки виртуальной машины VMware
Настройки виртуальной машины VMware

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

Например, у VMware для дисков обычно используется SCSI, а для сетевого адаптера — E1000E, эмулирующий сетевую карту Intel. Информация об устройствах также доступна в настройках виртуальной машины.

Настройки виртуальной машины VMware
Настройки виртуальной машины VMware

У QEMU-KVM есть замечательное устройство virtio, которое может использоваться для подключения дисков, для сетевых адаптеров и многого другого. Virtio не эмулирует известное операционной системе физическое устройство, как, например, сетевая карта Е1000, а представляется специализированным виртуальным устройством. Преимущество virtio — более высокая производительность по сравнению с эмуляцией.

Не все операционные системы поддерживают virtio, но для большинства актуальных ОС поддержка есть. При миграции рекомендуется переводить свои виртуальные машины на работу именно с virtio в части сети и дисковой подсистемы. Это позволит иметь высокую производительность для соответствующих подсистем виртуальной машины.

К сожалению, множество операционных систем, работающих на VMware, не содержат драйверы virtio «из коробки». Это и создает вторую и наиболее комплексную особенность при миграции.

Третьим хочется выделить вопрос необходимой инфраструктуры для миграции. В целом процесс миграции предполагает копирование .vmdk-диска, его конвертацию и добавление к виртуальной машине в новой среде виртуализации.

Каждая из этих процедур требует дисковой емкости, пропускной способности сети, вычислительных ресурсов. А если диски виртуальной машины большие, то понадобится много места. Требуемую емкость можно оценить как х2 от размера диска виртуальной машины. И следует не забывать о времени на конвертацию для больших дисков. Оно также будет немаленьким. Говорить об онлайн-переносе, конечно, не приходится. Любая подобная миграция будет сопряжена с остановкой виртуальной машины.

Подходы к миграции

С учетом обозначенной в предыдущем пункте особенности с устройствами ввода-вывода можно выделить два подхода:

  1. Миграция с помощью qemu-img и последующая установка драйверов.
  2. Миграция с помощью утилиты virt-v2v с автоматической установкой драйверов.

Наброски первого подхода уже были обозначены в предыдущей главе. Их можно обобщить в следующий план действий:

  1. Копирование и конвертация .vmdk-дисков в .qcow2-диски.
  2. Создание виртуальной машины в VMmanager с дисками не меньшего размера.
  3. Копирование конвертированных дисков на место дисков виртуальной машины.
  4. Корректировка конфигурационного xml-файла виртуальной машины, изменение типа устройств ввода-вывода.
  5. Установка необходимых драйверов в виртуальную машину.
  6. Корректировка конфигурационного xml-файла в исходное состояние.

А вот про утилиту virt-v2v выше ничего не сказано. Virt-v2v — это инструмент, который развивает компания RadHat. Утилита конвертирует виртуальные машины для работы на гипервизоре QEMU-KVM из виртуальных машин на других гипервизорах. Более подробно можно прочитать вводную статью от RedHat.

Ключевым преимуществом virt-v2v по сравнению с qemu-img является то, что virt-v2v не только конвертирует диски, но еще и добавляет в гостевую операционную систему нужные драйверы и предлагает конфигурационный xml-файл для виртуальной машины. Недостатком можно назвать то, что утилита поддерживает ограниченный набор операционных систем, а также при ее использовании снижается прозрачность происходящего при конвертации.

В этом случае план может состоять из следующих шагов:

  1. Копирование и конвертация .vmdk-дисков в .qcow2-диски.
  2. Создание виртуальной машины в VMmanager с дисками не меньшего размера.
  3. Копирование конвертированных дисков на место дисков виртуальной машины.

И если virt-v2v смогла установить драйверы virtio, то виртуальная машина успешно запустится.

Конфигурация стенда для миграции

Теперь можно перейти от общих соображений про миграцию к конкретным шагам.

Сначала пара слов о параметрах стенда и версиях используемого ПО:

  • VMware ESXi 7.0.3, 20328353 под управлением vCenter Server 7.0.3.00700.
  • Сервер платформы VMmanager 11365 (11.3.5) с добавленным узлом виртуализации на базе ОС Alma Linux 8.7, Qemu 6.2.0, Libvirt 8.0.0.

Узел использовался в качестве сервера конвертации.

В качестве гостевых операционных систем для тестирования использовались Windows Server 2016 и Alma Linux 8.7. Загрузчик — BIOS, в каждой виртуальной машине подключено два диска, добавлен один сетевой интерфейс.

Миграция с помощью qemu-img

Первым шагом «по умолчанию» следует создать резервные копии всего, что подлежит переносу. Какая бы безопасная операция ни была, резервные копии подстрахуют от невыявленных рисков.

Далее будут приведены шаги процесса миграции.


  1. Проверить установлены ли гостевые инструменты VMware (VMware guest tools) и удалить их, если они установлены

    Гостевые инструменты могут помешать работе виртуальной машины на новом гипервизоре.

    Для проверки на Alma Linux можно выполнить команду rpm -qa | grep open-vm. Если будут найдены установленные пакеты, значит, инструменты есть и их нужно удалить.

    Для удаления выполнить команду “rpm -e <имя найденного пакета>”. В моем случае — “rpm -e open-vm-tools-12.0.5-2.el8.x86_64”.

    Более подробно про удаление VMware tool на RedHat-подобных системах можно почитать по ссылке.

    Для удаления гостевых инструментов на Windows можно воспользоваться элементом панели управления «Программы и компоненты». Там же можно проверить, установлены ли гостевые инструменты, посмотрев список установленных программ.


  2. Перенести файлы виртуальной машины с VMware на сервер, где будет выполняться миграция

    Для инструмента qemu-img будет достаточно .vmdk-файлов, но для инструмента virt-v2v требуются также и конфигурационные .vmx-файлы.

    В примере будет скопирована вся папка с файлами виртуальной машины. Следует обратить внимание, что файл <имя виртуальной машины>.vmdk обычно содержит конфигурационную информацию (посмотреть ее можно как обычный текстовый файл командой: cat <имя файла. vmdk>). У файла с самим диском в названии есть суффикс flat. Например, у меня файл диска называется так: migration_test-flat.vmdk.

    Для копирования подойдет инструмент scp. Команда, копирующая с ESXi, выглядит так:

    
 scp -r root@<esxi ip-адрес>:/vmfs/volumes/<имя datastore>/<имя директории ВМ>/ <директория назначения>

    В моем случае:

     
 scp -r root@172.31.4.204:/vmfs/volumes/5e53a708/migration_test/ /migration

  3. Конвертировать диск .vmdk в формат .qcow2 с помощью qemu-img

    Общий вид команды:

     
 qemu-img convert -p -O qcow2  <путь до .vmdk-диска> <имя создаваемого qcow2-диска>

    Если у виртуальной машины несколько дисков, то конвертировать следует каждый из них. В моем случае команды выглядели следующим образом:

     
 qemu-img convert -p -O qcow2  ./migration_test-flat.vmdk  ./migration_test-flat.qcow2
 
     
 qemu-img convert -p -O qcow2  ./migration_test_1-flat.vmdk ./migration_test_1-flat.qcow2

  4. Создать виртуальную машину в интерфейсе VMmanager

    При создании виртуальной машины следует указать то же количество дисков, которое было у исходной виртуальной машины. Размер дисков выбрать не менее исходного размера дисков.


  5. Перенести сконвертированные диски вместо созданных дисков виртуальной машины

    Заменить диски виртуальной машины на сконвертированные .qcow2-диски. У VMmanager диски виртуальных машин по умолчанию находятся на узлах в директории /vm и идентифицируются по имени виртуальной машины. При переносе сконвертированного диска исходное имя созданного диска виртуальной машины должно сохраниться.

    Чтобы не перепутать диски местами, идентифицировать имя диска и директорию нахождения диска, можно воспользоваться xml-конфигурацией виртуальной машины. Конфигурация доступна на узле с виртуальной машиной по команде:

     
 virsh dumpxml <имя виртуальной машины>

  6. Скорректировать настройки устройств ввода-вывода в конфигурации виртуальной машины

    Если на данном этапе выполнить запуск виртуальных машин, то можно столкнуться с проблемой при загрузке. Alma Linux загружается в emergency-режиме, Windows также загружается в режиме восстановления.

    Emergency режим в Linux
    Emergency режим в Linux
    Режим восстановления в Windows
    Режим восстановления в Windows

    Причина такого поведения — отсутствие virtio-драйверов.

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

     
 virsh edit <имя виртуальной машины>

    Автоматически создаваемая конфигурация дисковой подсистемы и сетевых интерфейсов в моем примере выглядит так:

    
 <disk type='file' device='disk'>
     <driver name='qemu' type='qcow2'/>
     <source file='/vm/7_Mig_test_alma_qemuimg'/>
     <target dev='vda' bus='virtio'/>
     <boot order='1'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
 </disk>
 <disk type='file' device='disk'>
     <driver name='qemu' type='qcow2'/>
     <source file='/vm/8_Mig_test_alma_qemuimg_2'/>
     <target dev='vdb' bus='virtio'/>
     <boot order='2'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
 </disk>
 <interface type='bridge'>
     <mac address='52:54:00:56:30:d8'/>
     <source bridge='VLAN1129'/>
     <target dev='vm9_net0'/>
     <model type='virtio'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
 </interface>

    Как видно из конфигураций, везде используется тип устройства virtio.

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

    Как выяснилось дальше, драйверы virtio для Alma Linux содержатся в операционной системе, но не включены в состав initramfs, поэтому для запуска Alma Linux достаточно изменить устройства для дисковой системы. Для Windows же требуется заменить и дисковую систему и сетевое устройство.

    Скорректированные блоки конфигурационного файла в моем примере выглядят следующим образом:

    
 <disk type='file' device='disk'>
     <driver name='qemu' type='qcow2'/>
     <source file='/vm/7_Mig_test_alma_qemuimg'/>
     <target dev='sda' bus='ide'/>
     <boot order='1'/>
     </disk>
 <disk type='file' device='disk'>
     <driver name='qemu' type='qcow2'/>
     <source file='/vm/8_Mig_test_alma_qemuimg_2'/>
     <target dev='sdb' bus='ide'/>
     <boot order='2'/>
 </disk>
 <interface type='bridge'>
     <mac address='52:54:00:56:30:d8'/>
     <source bridge='VLAN1129'/>
     <target dev='vm9_net0'/>
     <model type='e1000'/>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
 </interface>

    Также параметры диска можно изменить в настройках VMmanager в веб-интерфейсе. Это доступно в настройках виртуальной машины «Виртуальные диски» → «Редактировать диск» → «Тип подключения».


  7. Запустить виртуальные машины в интерфейсе VMmanager

    Выполненные настройки позволяют запустить виртуальные машины и добиться загрузки операционной системы.


  8. Скорректировать настройки сетевых интерфейсов

    Следует учитывать, что после загрузки новые сетевые устройства будут представлены операционной системе как новые интерфейсы и потребуется их повторная настройка.


  9. Установить необходимые драйверы для операционных систем

    На следующем шаге требуется установить virtio-драйверы. Для WIndows это можно сделать, загрузив актуальные драйверы с сайта fedoraproject.org и выполнив настройки в операционной системе.

    Для Alma Linux, как было сказано выше, ситуация более интересная, так как драйверы фактически содержатся в операционной системе, но отсутствуют в initramfs, которая загружается до запуска ядра. В этом можно убедиться, выполнив команду:

     
 lsinitrd /boot/initramfs-4.18.0-425.3.1.el8.x86_64.img | grep virtio

    Если ее вывод будет пустым — значит, драйверы отсутствуют в initramfs.

    Проверить наличие драйверов virtio в системе можно командой: 

     
 find /lib/modules/$(uname -r)/kernel/drivers/ -iname "virtio

    Таким образом, для Alma Linux не требуется установка драйверов: достаточно добавить в initramfs нужные драйверы. Процедура описана в соответствующей статье на сайте RedHat.

    Все сводится к созданию файла /etc/dracut.conf.d/virtio.conf с содержимым:

     
 add_drivers+=" virtio_scsi virtio_blk virtio_net "

    — и последующему запуску сборки initramfs командой dracut -f.


  10. Восстановить xml-конфигурацию виртуальной машины в исходное состояние

    После проделанных манипуляций можно остановить виртуальные машины и восстановить исходную xml-конфигурацию в части устройств ввода-вывода.

    С учетом выполненных изменений виртуальные машины должны успешно загружаться с устройствами ввода-вывода virtio.


  11. Установить новые гостевые инструменты

    В конце процедуры миграции нужно установить гостевые инструменты для работы с QEMU-KVM, то есть установить QEMU Guest agent. Инструкции легко найти в интернете или воспользоваться встроенным функционалом установки гостевого агента в VMmanager.


Миграция с помощью virt-v2v

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

Важные материалы по работе утилиты:

Но прежде чем использовать утилиту, ее следует установить:


 
 dnf install virt-v2v

  1. Подготовка к использованию утилиты

    На первом шаге следует выполнить подготовительные задачи. Так же, как и в предыдущем разделе, удалить гостевые инструменты VMware и загрузить файлы виртуальных машин на сервер конвертации.

    Утилита virt-v2v позволяет подключиться к vCenter Server и автоматически загрузить файлы виртуальных машин в процессе конвертации, но в рамках этой статьи файлы будут загружены локально.

    В случае конвертации Windows нужно проверить, есть ли на виртуальной машине, выполняющей конвертацию, драйверы virtio для Windows системы. Для этого можно посмотреть, есть ли директория virtio-win по пути: /usr/share/virtio-win. Если директория virtio-win отсутствует, то драйверов нет и их нужно загрузить.

    Подробно процесс описан в статье. Самая простая из опций — добавить репозиторий и выполнить команду по установке dnf install virtio-win.


  2. Выполнить конвертацию виртуальной машины

    Для конвертации запустить утилиту virt-v2v, указав путь до .vmx-файла виртуальной машины. Следует обратить внимание, что указывается путь именно до .vmx-файла, а не до .vmdk-файлов. Остальные файлы виртуальной машины должны быть в той же директории, что и vmx-файл.

     
 virt-v2v -i <путь до .vmx файла> -o local -of qcow2 -os <директория с файлами после конвертации>

    В моем случае команда выглядела так:

     
 virt-v2v -i vmx ./win_mig_test.vmx -o local -of qcow2 -os /mig

    Результат работы virt-v2v выводится в консоли:

    Результат работы virt-v2v выводится в консоли

    Во время конвертации могут происходить ошибки прав доступа к .vmdk-файлу. Для их исправления была использована команда по смене владельца .vmdk-файлов на qemu:


     
 chown qemu:qemu <путь до файлов .vmdk>

  3. Создать виртуальную машину и подменить файлы дисков виртуальной машины

    Повторить шаги 4 и 5 из предыдущего раздела. После этого виртуальную машину можно запускать. В нашей лабораторной виртуальные машины с Windows 2016 и Alma Linux 8.7 успешно запустились.

    После запуска виртуальной машины потребуется перенастроить сетевые интерфейсы, а также не забыть установить гостевые инструменты QEMU Guest agent.

    В рамках нашей лабораторной для Windows 2016 второй диск оказался в состоянии offline, что тоже легко исправить в меню управления дисками.

    Управление дисками в Windows
    Управление дисками в Windows

Заключение

Из описанного выше можно сделать вывод, что миграция виртуальных машин — это проектная задача, которая требует проектного подхода. Мигрировать «по-быстрому», скорее всего, не получится или может вызвать проблемы в будущем.

Для миграции нужно прорабатывать перенос каждой виртуальной машины, тестировать конкретные версии операционных систем и драйверов. Хорошая новость, что в большинстве случае проблемы удается преодолеть и миграция проходит успешно.


Попробовать VMmanager