Миграция виртуальной машины oVirt 4.2 на Hyper-V (конвертация в VHDX)

Последний опыт общения с технической поддержкой HPE относительно проблемы работоспособности виртуальной машины c ПО 3PAR Virtual Service Processor (VSP) выявил интересный факт. В один прекрасный момент наш виртуальный сервер VSP перестал отправлять информацию о состоянии СХД 3PAR на серверы сбора логов на стороне HPE. При этом тесты на проверку подключения к серверам HPE из веб-интерфейса VSP (SPOCC) проходили успешно. Диагностика проблемы инженером поддержки 3PAR показала, что отсылка файлов ломается на этапе проверки информации о платформе виртуализации VSP. Наша виртуальная машина была развёрнута на oVirt, и, как я понял, сервер сбора HPE с какого-то момента времени стал считать это криминалом.

Мне хорошо было известно, что в документации к VSP была заявлена поддержка VMWare и Hyper-V, но так в своё время все наши ВМ на базе Linux были перенесены с Hyper-V на oVirt, в тоже время на oVirt была заново развёрнута и виртуальная машина с VSP. И, что интересно, в то время все функции VSP, в том числе и отправки логов СХД на коллекторы HPE, работали без нареканий и вопросов. А теперь инженер поддержки 3PAR сказал о том, что никаких вариантов решения, кроме переноса VSP на VMWare/Hyper-V, наша проблема не имеет. Честно говоря, я был очень удивлён тем обстоятельством, что HPE предлагают эксплуатировать свой Virtual Appliance VSP, сделанный на базе Red Hat Enterprise Linux без поддержки виртуализации от Red Hat, вернее даже сказать, с выраженным её отсутствием. Таким образом, в результате этой истории, у меня возникла необходимость в переносе виртуальной машины VSP с oVirt на Hyper-V. Здесь знатоки 3PAR/VSP скажут, что, возможно, проще было бы заново развернуть и настроить аплайнс на Hyper-V. Однако затевался этот перенос больше “из спортивного интереса”, чтобы получить знание о том, каким набором манипуляций можно выполнить миграцию виртуальной машины из oVirt в Hyper-V.

В представленных ниже двух вариантах по сути выполняется конвертация не самой виртуальной машины oVirt со всеми её настройками, а лишь конвертация виртуальных дисков ВМ oVirt в совместимый с Hyper-V формат VHDX. После такой конвертации предполагается создание новой виртуальной машины Hyper-V с присоединением к ней конвертированных дисков VHDX. Для конвертации дисков в обоих способах будут использоваться возможности утилиты qemu-img на ОС Windows Server 2012 R2 и CentOS Linux 7.5.

Способ №1. Конвертация из OVA в VHDX на стороне Windows Server

Веб-консоль используемой в нашем случае версии oVirt 4.2.4 имеет функцию экспорта виртуальной машины в виде файла-контейнера Open Virtual Appliance (OVA) в указанный нами каталог на любой хост кластера oVirt. Однако в Hyper-V формат OVA, как таковой, не поддерживается, поэтому нам потребуется конвертация данных OVA в понятный для Hyper-V формат VHDX.

Напомню, что ранее мы уже рассматривали один из вариантов похожей конвертации в статье Конвертация виртуального диска VMDK из OVA-шаблона VMWare в VHDX для Hyper-V. Однако в случае использования этого варианта потребуется установка Microsoft Virtual Machine Converter, для возможности работы с Powershell-командлетами этой утилиты. В этот раз мы воспользуемся более простой утилитой командной строки, не требующей установки - qemu-img. Загрузить копию этой утилиты для платформы Windows можно по ссылке Cloudbase Solutions : qemu-img for Windows

Общий план действий будет такой:

1. В веб-консоли oVirt выполняем экспорт виртуальной в формат OVA
2. Копируем OVA-шаблон ВМ на хост Hyper-V, распаковываем OVA и с помощью qemu-img конвертируем диск формата QCOW2 в формат VHDX
3. Создаём в Hyper-V новую ВМ с подключением VHDX диска.

Учитывая то обстоятельство, что экспорт виртуальной машины в формат OVA будет выполняться на одном их хостов кластера oVirt, прежде, чем приступать к экспорту, нам нужно проверить фактический размер дисков ВМ и удостовериться в том, что на хосте достаточно свободной дисковой ёмкости. Подглядеть фактический размер диска ВМ можно в веб-консоли oVirt. В разделе Compute > Virtual Machines выберем интересующую нам машину и открыв её свойства переключимся на вкладку Snapshots , затем выберем Active VM > Disks.  Здесь обратим внимание на значение свойства Actual Size.

Прежде, чем приступить к экспорту виртуальной машины в формат OVA в веб-консоли oVirt, нам потребуется завершить работу это виртуальной машины.

После того, как виртуальная машина будет выключена, в меню расширенном меню действий станет доступен пункт Export as OVA.

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

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

По окончании процедуры экспорта нам нужно скопировать получившийся OVA-файл на хост виртуализации Hyper-V. Сделать это можно, например, воспользовавшись утилитой pscp на стороне Windows-сервера.

pscp.exe root@KOM-AD01-VM11:/tmp/KOM-HPVSP.ova D:\Temp

Имейте ввиду то, что в дальнейшем для распаковки и конвертации диска ВМ на стороне Windows-сервера нам потребуется определённый объём свободного дискового пространства, то есть, как минимум, двойной объём размера OVA-файла.

Распакуем OVA-файл любым архиватором, например 7-zip. Внутри OVA-контейнера мы найдём XML-конфигурацию ВМ в формате OVF и диск виртуальной машины в формате QCOW2

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

qemu-img info "D:\Temp\KOM-HPVSP\6a7ced92-57ae-4a07-b458-e45c2ccf38e0"

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

Выполняем команду конвертации в формат динамического диска VHDX:

qemu-img convert -O vhdx -o subformat=dynamic "D:\Temp\KOM-HPVSP\6a7ced92-57ae-4a07-b458-e45c2ccf38e0" "D:\Temp\KOM-HPVSP\Disk1.vhdx"

По окончании процесса конвертации можем проверить получившийся VHDX-файл, вызвав в консоли Hyper-V Manager функцию Inspect Disk, чтобы удостовериться в том, что формат файла корректный и компоненты виртуализации Windows способны прочитать информацию о диске. Аналогичную проверку можно выполнить с помощью Powershell-командлета Get-VHD.

Как видим, в нашем примере диск успешно распознан, значит мы можем создать новую виртуальную машину Hyper-V и подключить к ней этот диск. В нашем случае создана виртуальная машина Gen1, так как переносимая ВМ VSP не сможет работать в режиме Gen2.

После создания виртуальной машины пробуем выполнить её запуск и убеждаемся в том, что гостевая ОС успешно запускается.

При первом запуске виртуальной машины гостевая ОС RHEL6 может загрузиться без доступа к сети из-за смены MAC-адреса виртуального сетевого интерфейса. Лечится это нехитрой правкой конфигурационного файла /etc/udev/rules.d/70-persistent-net.rules в гостевой ОС, как это было описано ранее в заметке После миграции между хостами в кластере Hyper-V на виртуальной машине HP 3PAR Virtual Service Processor 4.3.0 перестала работать сеть. И, возможно, для такой ВМ разумным будет назначение статического MAC-адреса в свойствах виртуальной машины Hyper-V.

Нет root-доступа к виртуальному серверу VSP, чтобы поправить конфигурацию сети в гостевой ОС Linux после миграции виртуальной машины? Не беда. Воспользуйтесь принципом получения root-доступа, описанным ранее в статье Первичная настройка HP 3PAR StoreServ 7200 - Разворачиваем виртуальную машину HP 3PAR Virtual Service Processor 4.3.0 на Hyper-V в Windows Server 2012 R2

В заключительной стадии нам остаётся только установить в гостевую ОС компоненты интеграции Hyper-V и не забыть удалить все временные файлы, которые мы создавали на этапе конвертации.

Способ №2. Конвертация из QCOW2 в VHDX на стороне Linux-хоста oVirt

Суть второго способа отличается от вышеприведённого первого способа тем, что первичный экспорт виртуальной машины oVirt выполняется не в OVA-шаблон, а в Export Domain с последующей конвертацией образа диска на стороне Linux-хоста oVirt. Таким образом, общий план действий будет следующим:

1. В веб-консоли oVirt выполняем экспорт виртуальной в Export Domain
2. Находим в хранилище Export Domain диск и утилитой qemu-img конвертируем его в VHDX
3. Создаём в Hyper-V новую ВМ с подключением VHDX диска

Прежде, чем приступить к экспорту виртуальной машины в Export Domain в веб-консоли oVirt, нам потребуется завершить работу это виртуальной машины. После того, как виртуальная машина будет выключена, в меню расширенном меню действий станет доступен пункт Export to Export Domain.

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

Процедура экспорта может занять некоторое время, в зависимости от размера ВМ, производительности Data Domain, на котором расположена исходная ВМ, производительности дисков Export Domain, производительности сети и других условий. , чтобы отследить статус выполняющейся задачи экспорта, нажмём в правом верхнем углу веб-консоли oVirt значок Tasks.

По завершению процедуры экспорта нам нужно найти файлы экспортированной виртуальной машины в хранилище Export Domain.

На любом хосте кластера oVirt, к которому подключен Export Domain по протоколу NFS, можно найти каталог /rhev/data-center/mnt/, в который монтируется хранилище Export Domain.

# ls -l /rhev/data-center/mnt/

...
drwxr-xr-x. 6 vdsm kvm 4096 Feb 16 11:30 blockSD
drwxr-xr-x. 3 vdsm kvm 4096 Jul 27 15:15 kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-iso-domain
drwxr-xr-x. 3 vdsm kvm 4096 Jul 26 14:12 kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-vm-backup

В нашем примере смонтированное хранилище Export Domain расположено в каталоге /rhev/data-center/mnt/kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-vm-backup. В этом каталоге нам нужно пройти в подкаталоги вида ../{Storage Domain ID}/images/{Image Group ID}/

Подкаталог с идентификатором {Storage Domain ID} будет скорее всего только один, поэтому не промахнёмся, а вот внутри подкаталога …/images/ может оказаться множество подкаталогов, среди которых найти каталог, относящимся к интересующей нас экспортированной виртуальной машине может оказаться не так просто.

Для начала давайте заглянем в веб-консоль oVirt в свойства виртуальной машины на вкладку Snapshots и скопируем Disk Snapshot ID для основного снимка машины. В нашем случае это f99fbeeb-96db-4d56-9108-8e9e243e828d

Зная этот идентификатор основного снимка виртуальной машины, мы сможем найти расположение её файлов в хранилище Export Domain на хосте oVirt, указав в качестве базы для поиска каталог хранилища и в качестве маски имени – идентификатор снимка машины.

# find /rhev/data-center/mnt/kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-vm-backup/* -name "*f99fbeeb-96db-4d56-9108-8e9e243e828d*"

/rhev/data-center/mnt/kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-vm-backup/a5fd935b-8cb8-4331-8549-5854553dac25/images/0776082f-0ac4-4be9-8250-2a0053362188/f99fbeeb-96db-4d56-9108-8e9e243e828d.meta
/rhev/data-center/mnt/kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-vm-backup/a5fd935b-8cb8-4331-8549-5854553dac25/images/0776082f-0ac4-4be9-8250-2a0053362188/f99fbeeb-96db-4d56-9108-8e9e243e828d

Как видим, в нашем примере интересующие нас файлы расположены в подкаталоге /rhev/data-center/mnt/kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-vm-backup/a5fd935b-8cb8-4331-8549-5854553dac25/images/0776082f-0ac4-4be9-8250-2a0053362188/. Здесь же можем обратить внимание на их размер и дату создания.

# ls -lh /rhev/data-center/mnt/kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-vm-backup/a5fd935b-8cb8-4331-8549-5854553dac25/images/0776082f-0ac4-4be9-8250-2a0053362188/

total 23G
-rw-rw----. 1 vdsm kvm 23G Jul 27 16:51 f99fbeeb-96db-4d56-9108-8e9e243e828d
-rw-r--r--. 1 vdsm kvm 269 Jul 27 16:51 f99fbeeb-96db-4d56-9108-8e9e243e828d.meta

Файл *.meta, как я понимаю, это файл описания метаданных снимка. Рядом с ним лежит образ диска нашей виртуальной машины.

С помощью утилиты qemu-img посмотрим информацию о диске и его типе:

# qemu-img info /rhev/data-center/mnt/kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-vm-backup/a5fd935b-8cb8-4331-8549-5854553dac25/images/0776082f-0ac4-4be9-8250-2a0053362188/f99fbeeb-96db-4d56-9108-8e9e243e828d

image: /rhev/data-center/mnt/kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-vm-backup/a5fd935b-8cb8-4331-8549-5854553dac25/images/0776082f-0ac4-4be9-8250-2a0053362188/f99fbeeb-96db-4d56-9108-8e9e243e828d
file format: qcow2
virtual size: 256G (274877906944 bytes)
disk size: 23G
cluster_size: 65536
Format specific information:
    compat: 0.10
    refcount bits: 16

Теперь с помощью этой же утилиты выполняем конвертацию в формат VHDX:

# qemu-img convert -O vhdx -o subformat=dynamic -p /rhev/data-center/mnt/kom-fs.holding.com:_mnt_quadstor-vd1_nfs_ovirt-vm-backup/a5fd935b-8cb8-4331-8549-5854553dac25/images/0776082f-0ac4-4be9-8250-2a0053362188/f99fbeeb-96db-4d56-9108-8e9e243e828d /tmp/KOM-HPVSP_Disk1.vhdx

Получившийся на выходе виртуальный диск в формате VHDX остаётся скопировать на хост с OC Windows Server и, по аналогии тем, что было описано выше, создать с использованием этого диска новую виртуальную машину Hyper-V.