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

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

На самом деле исходная ситуация в нашем случае заключалась в том, что нужно было развернуть новый виртуальный сервер именно в среде Hyper-V, так как поставляемый под эту задачу сконфигурированный компанией Avaya образ виртуальной машины (Virtual Appliance для управления IP АТС) поставлялся в виде образа диска VHDX. Однако немного "покрутив" этот образ, стало понятно, что здесь есть несколько проблем. Во-первых, оказалось, что внутри виртуального диска была "поселена" гостевая ОС Linux на базе CentOS 6 с древним ядром Linux версии 2.6. При этом в гостевой ОС не было никакого намёка на компоненты интеграции Hyper-V, которые, как минимум, позволили бы вменяемо управлять отключением ВМ с хоста и использовать "горячее" резервное копирование ВМ такими средствами, как System Center DPM, без опасения за то, что очередная "заморозка" системы может привести к проблемам с ПО в гостевой ОС. Во-вторых, учитывая "престарелость" гостевой ОС стало очевидно, что нет никаких шансов запустить виртуальный диск на ВМ второго поколения (Hyper-V Gen2), и придётся "прозябать" на старом тормозном виртуальном IDE контроллере "со всеми вытекающими". Такое положение вещей мне, мягко говоря, не понравилось, и было решено завести эту виртуальную машину на более дружелюбный для её гостевой ОС системе управления виртуализацией - oVirt. Соответственно встал вопрос миграции имеющегося VHDX диска в форматы, совместимые с oVirt.

Документ oVirt Admin Guide - Understanding Virtual Disks гласит, что oVirt-у можно "скармливать" такие QEMU-совместимые форматы, как QCOW2 или RAW. Насколько я понимаю, формат QCOW2 используется в основном для динамически расширяемых дисков, то есть "Thin provision" в терминологии oVirt. А формат RAW больше можно отнести к полноразмерным статическим дискам, то есть "Preallocated" в терминологии oVirt.

Чтобы было понятно, почему всё дальнейшее описание отталкивается от идеи того, что нам потребуется преобразовать имеющейся VHDX диск именно в RAW-формат, поясню, что несколько разных попыток загрузки виртуального диска в других форматах в работающий у нас oVirt 4.2.6 оказались безрезультатными, вернее все они в разных сценариях завершались разными ошибками. Говоря о проблеме загрузки дисков в формате QCOW2, стоит отметить тот факт, что компетентный представитель Red Hat в ветке обсуждения oVirt HE 4.2.6 - Cannot upload a QCOW2 disk image via oVirt Administration Portal сказал, что эта проблема (Bug 1627032 и Bug 1635830) должна быть решена в следующей версии oVirt 4.2.7 и даже предложил некоторое обходное решение для тех, кому "приспичило".

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

Подготовка VHDX диска

Учитывая то обстоятельство, что в дальнейшем мы будем конвертировать имеющийся VHDX диск из динамического (именно в таком виде поставляется в нашем случае Virtual Appliance) в статический полноразмерный RAW-формат, ради экономии дискового пространства и ускорения всех последующих операций, нам желательно будет выполнить предварительно усечение (Shrink) и сжатие (Compact) VHDX диска средствами управляющих PowerShell-командлетов Hyper-V.

На стороне хоста Hyper-V посмотрим сведения об исходном диске VHDX

Get-VHD "C:\Temp\KOM-PBX01\disk.vhdx"

В нашем случае диск имеет конфигурацию с бОльшим размером (Size), чем, предположим, нам хотелось бы. Рассматриваемая гостевая ОС настроена поставщиком таким образом, что выполняет некоторые манипуляции по разметке диска при первом запуске, поэтому у нас фактически на диске много пустого места, которое можем попробовать "подрезать" через Shrink.

Сделаем небольшое отступление с парой примеров о том, как вообще понять, возможно ли усечение имеющегося у нас VHDX диска.

В типичной ситуации, когда внутри виртуального диска уже создан какой-либо раздел или разделы статического типа, и они занимают всю ёмкость диска, то мы увидим, что MinimumSize равный или максимально приближенный к размеру Size. И такой диск без дополнительных манипуляций мы не сможем усечь. Вот пример данных о диске другой виртуальной машины с OC Windows, где в гостевой ОС тип диска определён как Basic, а логические диски занимают весь объём виртуального диска.

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

Если же внутри диска разметка логических дисков имеет динамический тип (не путать с динамическими виртуальными дисками), то мы получим ситуацию, когда значение MinimumSize будет пустым, либо будет меньше значения Size. Вот пример данных о диске ещё одной виртуальной машины с OC Windows, где в гостевой ОС тип диска определён как Dynamic, и имеющийся на нём логический диск при этом занят примерно на 25%.

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

Итак, вернёмся к нашей задаче и обратим внимание на значения параметров MinimumSize и Size. В нашем случае они имеют значения 11812208640, то есть 11GB, и 107374182400, то есть 100GB, соответственно. То есть у нас есть техническая возможность усечь такой диск до 11GB.

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

Resize-VHD "C:\Temp\KOM-PBX01\disk.vhdx" -SizeBytes 30GB

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

Проверяем результат:

Get-VHD "C:\Temp\KOM-PBX01\disk1.vhdx"

Как видим, теперь размер диска определён в 30GB. Можем переходить к конвертации диска в RAW формат.

Конвертация VHDX в RAW

Конвертация виртуального диска в RAW формат создаст нам полноразмерный диск, равный полному объему виртуального размера диска VHDX (того, что указан в значении Size). Именно по этой причине мы предварительно провели мероприятия по уменьшению размера диска.

Для конвертации образа диска из формата VHDX в RAW на ОС Windows Server 2012 R2 воспользуемся утилитой командной строки, не требующей установки - qemu-img. Загрузить копию этой утилиты для платформы Windows можно по ссылке Cloudbase Solutions : qemu-img for Windows. Версия 2.3.0 для Windows x64

Для начала выполним команду проверки исходного диска с опцией исправления всех обнаруженных ошибок (перед этим не помешает сделать резервную копию диска, если на нём важные данные, а копии ещё не было сделано ранее):

qemu-img.exe check -r all "C:\Temp\KOM-PBX01\disk.vhdx"

Посмотрим информацию о диске:

qemu-img info "C:\Temp\KOM-PBX01\disk.vhdx"

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

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

qemu-img convert -p -O raw "C:\Temp\KOM-PBX01\disk.vhdx" "C:\Temp\KOM-PBX01\disk.raw"

В нашем случае конвертация, выполнявшаяся на физическом накопителе SAS 3G 15K, динамического 9GB виртуального VHDX-диска в полноразмерный 30GB RAW-диск прошла примерно за 6 минут.

Итак, виртуальный диск, который мы можем загрузить в oVirt готов, и теперь нам необходимо проверить то, что наша инсталляция oVirt удовлетворяет требованиям, которые выдвигаются для успешной работы механизма загрузки образов виртуальных дисков через интерфейс веб-узла oVirt Administration Portal.

Предварительные требования oVirt

Общие предварительные требования, которые нужно выполнить для возможности загрузки виртуальных дисков на веб-узле oVirt Administration Portal можно найти по ссылке oVirt Admin Guide - Uploading Images to a Data Storage Domain. Далее обозначим свои особенности по каждому из них.

Поддержка HTML5

Тут всё просто. На клиентском компьютере браузер, используемый для подключения к веб-узлу oVirt должен иметь поддержку HTML5. Это, например, браузеры не ниже Firefox 35, Internet Explorer 10, Chrome 13.

Доверие браузера сертификатам oVirt

Клиентский браузер должен доверять сертификату веб-узла Administration Portal. Получить корневой сертификат oVirt Engine можно по ссылке типа:

https://{oVirt Engine Server FQDN}/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA

Загруженный сертификат добавляем в хранилище доверенных корневых сертификатов в браузере, чтобы браузер не выдавал предупреждений безопасности для всех сертификатов, используемых для разных служб oVirt (в нашем случае имеет значение сертификат для службы ovirt-imageio-proxy) и подписанных данным корневым сертификатом.

Если ранее мы настраивали собственные сертификаты на стороне oVirt Engine, как, например, было описано здесь, то возможно, мы заходим использовать этот же сертификат и для работы ovirt-imageio-proxy. Я такой замены делать не пробовал, но для тех, кто надумает, приведу пару ссылок, которые могут оказаться полезными:

• Bug 1385617 - ovirt-imageio-proxy SSL certificate process undocumented
• oVirt How-To - Migrate PKI to SHA256 signatures Howto

Настроенная служба ovirt-imageio-proxy

На сервере oVirt Engine должна быть запущена и сконфигурирована служба ovirt-imageio-proxy. Об участии этой службы в процессе загрузки образа диска можно почитать в документе oVirt Image I/O.

Перейдём в консоль сервера oVirt Engine и убедимся в том, что служба работает:

# systemctl status ovirt-imageio-proxy

Проверим сконфигурировано ли в oVirt имя веб-узла для службы ovirt-imageio-proxy:

# engine-config --get ImageProxyAddress

Как видим, в нашем случае в качестве имени узла указано имя localhost, что по некоторым данным может привести к проблемам с корректной работой этой службы. Зададим в качестве имени узла FQDN сервера oVirt Engine с последующим перезапуском служб ovirt-engine и ovirt-imageio-proxy:

# engine-config -s ImageProxyAddress=kom-ad01-ovirt1.holding.com:54323
# systemctl restart ovirt-engine
# systemctl restart ovirt-imageio-proxy

В целом, этой несложной настройки достаточно для того, чтобы служба ovirt-imageio-proxy работала без ошибок.

Таймаут ожидания для службы ovirt-engine

Если мы планируем использовать для загрузки в oVirt виртуальные диски больших размеров, или диски небольшие, но при этом сеть у нас не самая быстрая, то мы можем столкнуться с истечением таймаута процедуры загрузки, получив сообщение типа "...timeout due to transfer inactivity, increase the timeout value". Чтобы избежать этой проблемы, предварительно увеличим таймаут ожидания по умолчанию на сервере Engine через конфигурационную опцию TransferImageClientInactivityTimeoutInSeconds. Обратите внимание на то, что эта опция доступна oVirt только начиная с версии 4.2.2.

Проверим значение, установленное по умолчанию:

# engine-config --get TransferImageClientInactivityTimeoutInSeconds

Как видим, сейчас таймаут равен 60 секундам, что в большинстве случаев может оказаться недостаточным значением. Увеличим значение, например, до 60 минут и для вступления изменений в силу перезагрузим службу ovirt-engine:

# engine-config -s TransferImageClientInactivityTimeoutInSeconds=3600
# systemctl restart ovirt-engine

На этом всё. Теперь мы можем считать, что наш oVirt Engine готов к загрузке образов виртуальных дисков.

Загружаем виртуальный диск в oVirt

На веб-узле oVirt Administration Portal переходим в раздел Storage > Storage Domains, выбираем домен хранения, в который мы ходим загрузить образ диска, переходим на вкладку Disks и в правом углу жмём кнопку Upload. В выпадающем меню выбираем пункт Start

В открывшейся форме Upload Image выберем ранее подготовленный нами RAW-диск, укажем для этого диска понятный нам Alias, и обязательно в низу формы нажмём кнопку Test Connection, чтобы проверить возможность соединения со службой ovirt-imageio-proxy. Если в результате теста мы получим какую-либо ошибку или браузер ругнётся на недовершённый сертификат, то до устранения этой проблемы пытаться выполнять загрузку смысла не имеет. В таком случае возвращаемся в выше описанный здесь раздел Предварительные требования oVirt, и внимательно проверяем все указанные в нём пункты. Если же проверка прошла успешно, можем запускать процесс загрузки образа, нажав кнопку OK.

За текущим состоянием загрузки диска мы можем следить в колонке Status в таблице со списком дисков домена хранения.

Если в процессе загрузки образа процедура по какой-то причине (например, временная ошибка сети) перейдёт в паузу, то можно попробовать возобновить процедуру пунктом Resume из выпадающего меню кнопки Upload. В этом же меню можно самостоятельно перевести процесс в паузу, а также совсем отменить запущенный процесс.

Дожидаемся успешного окончания процесса загрузки, до появления статуса "OK" в колонке Status.

На этом процесс загрузки образа виртуального диска в домен хранения oVirt считаем завершённым.

Дополнительно стоит заметить, что если в ходе вышеописанного процесса загрузки образа у нас всё-таки возникают какие-то ошибки, то первым делом стоит изучать следующие лог-файлы:

• На сервере oVirt Engine: /var/log/ovirt-imageio-proxy/image-proxy.log
• На хосте, через который производится загрузка: /var/log/ovirt-imageio-daemon/daemon.log

Настраиваем виртуальную машину oVirt

Создаём в oVirt новую виртуальную машину и в свойствах этой ВМ на вкладке General используем кнопку Attach, чтобы присоединить к ВМ ранее загруженный виртуальный диск.

При подключении диска выбираем интерфейс (в нашем случае доступен IDE или VirtIO) и, если на диске загружаемая ОС, включаем признак в столбце "OS"

После того, как свойства виртуальной машины сохранены и в oVirt произведена привязка образа диска к ВМ, можем снова открыть свойства диска кнопкой Edit

Здесь мы можем заменить интерфейс на более "модный" VirtIO-SCSI.

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

Не забываем про то, что для полноценной работы гостевой ОС в среде виртуализации, нужно установить компоненты интеграции oVirt (oVirt Guest Agent).

Заключение

В целом, можем считать, что конечный результат достигнут – диск виртуальной машины Hyper-V успешно сконвертирован, импортирован и запущен в среде виртуализации oVirt.

Однако если нас не устраивает то, что в процессе загрузки диск вынужденно был превращён в полноразмерный, учитывая его возможную неполную утилизацию внутри гостевой ОС, то у нас может возникнуть дополнительное желание преобразовать диск в среде oVirt из типа "Preallocated" в тип "Thin provision". В таком случае мы можем воспользоваться рекомендациями из статьи How to convert preallocated disks to thin provisioned disks?. Общий смысл этих рекомендаций сводится к тому, что у нас есть два основных варианта для преобразования диска ВМ в тип "Thin provision":

• Клонирование текущей ВМ со статическим диском (Preallocated) в новую ВМ с динамическим Thin-диском
• Подключение к ВМ дополнительного Thin-диска с последующим копированием содержимого гостевой системы с помощью утилиты dd и отключением исходного Preallocated-диска

На этом всё. Удачных миграций.