Перенос виртуальных машин с xenserver на hyper-v

Конвертируем виртуальные машины VMWare в Hyper-V и обратно

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

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

Сегодня мы расскажем, как это сделать для двух наиболее популярных систем виртуализации VMWare и Hyper-V.

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

Форматы виртуальных дисков у разных гипервизоров также различны, однако это не представляет сложности – достаточно использовать специализированное ПО для конвертации.

Единственная тонкость – гостевая ОС должна поддерживаться обоими типами гипервизора.

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

Рассмотрим процесс на реальном примере.

Один наш клиент приобрел коробочную версию “Мегаплан”, который разработчики распространяют весьма оригинальным способом: в виде образа виртуальной машины формата Open Virtualization Format (OVF), который поддерживают VMWare и VirtualBox.

Собственно, внутри виртуалки содержится Ubuntu 12.04 с настроенным веб-сервером, СУБД и прочими компонентами необходимыми для работы “Мегаплана”, который представляет собой обычное веб-приложение. При этом лицензионное соглашение запрещает доступ к гостевой ОС.

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

Если с VMWare это не составляет особых проблем, OVF импортируют все ее продукты “из коробки”, то владельцам Hyper-V повезло меньше, импорт OVF возможен только через модуль к System Center – Virtual Machine Manager. Поэтому придется идти другим путем – конвертацией виртуальной машины формата VMWare.

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

Если виртуальная машина уже работала на платформе VMWare (как чаще всего и бывает), то удаляем из нее VMWare Tools и выключаем машину.

Теперь можно приступать к конвертации виртуального диска. Для этого воспользуемся бесплатной утилитой StarWind V2V Converter. Ее интерфейс и использование предельно просты. Выберем исходный виртуальный диск (файл с расширением vmdk).

Как видим, это расширяемый диск размером 97,7 ГБ, теперь выберем необходимый формат, для Hyper-V это формат MS Virtual PC. Нам доступны два варианта диска: расширяемый (growable) и pre-allocated, когда место выделяется на диске сразу. Нас интересует первый вариант.

По окончании конвертации в папке с виртуальной машиной появится второй файл виртуального диска в формате Hyper-V.

Его следует скопировать отсюда и разместить в хранилище виртуальных дисков Hyper-V.

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

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

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

Что можно сделать еще? Если вы используете Hyper-V 3.0 и старше (доступны начиная с Windows Server 2012) то имеет смысл еще раз преобразовать виртуальный диск в новый формат VHDX. Для этого выключите виртуальную машину, перейдите в настройки диска и нажмите кнопку Правка.

В появившемся мастере выберите Преобразовать, укажите формат (VHDX) и тип (расширяемый) диска, а также его имя и расположение:

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

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

Конвертация Hyper-V виртуальных машин в VMWare производится аналогичным образом. Конвертируем виртуальный диск в VMDK, если использовался диск формата VHDX, то предварительно его следует преобразовать в VHD средствами Hyper-V аналогично тому как мы делали выше.

Затем создаем в VMWare виртуальную машину для используемой гостевой системы с идентичными параметрами и в настройках диска указываем использовать сконвертитрованый нами VMDK диск.

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

Источник: https://interface31.ru/tech_it/2014/03/konvertiruem-virtualnye-mashiny-vmware-v-hyper-v-i-obratno.html

Перенос виртуальной машины VMware на Hyper-V

Перенос виртуальной машины VMware на Hyper-V – мой опыт переноса виртуальной машины с VMware Workstation на Hyper-V.

Предисловие

Знаю VMware очень плохо и пока знать лучше и не собираюсь. Нельзя сказать, что горжусь этим, но точно не стыжусь – мой выбор Hyper-V, делаю ставку на него, особенно в свете выхода бесплатного HVS. MS решила “порвать всех” в нише гипервизоров и пока ей это удается.

Итак, есть машина CentOS под VMware Workstation 12.5, работает она только при залогиненном пользователе, как только выходишь с сервера – машина выключается.

Кто-то наверное посмеётся – “да это просто решается, нужно всего лишь прикрутить 33 костыля и всё сразу заработает”, но мне это неинтересно. К тому же VMware насоздавала каких-то сетевых подключений, разбираться что это – мне тоже не хочется.

Сервер тупит, в Server Manager его обновление происходит дольше всего. Значит переносим в Hyper-V, VMware киляем.

Перенос

Сначала нужно удалить VMware Tools.

После этого смотрим в свойствах машины как точно называется файл диска, поскольку у VMware Workstation диск – это не один файл, а целая куча файлов и качаем утилиту V2V Converter. Для скачивания потребуется создать учетную запись и подтвердить e-mail, процедура мутноватая, после чего приходит письмо со ссылкой для скачивания.

Далее выключаем машину, указываем файл диска VM, формат создаваемого файла – MS Virtual PC growable image, место назначения файла и его название. Время конвертирования файла зависит от размера файла жесткого диска, а скорость конвертации составляет где-то 10-12MB/s, у меня по крайней мере было так – то есть довольно долго (для машины с диском 300Gb+).

Затем копируем получившийся файл vhd, кстати, размер его получился где-то на 5% меньше чем изначальный суммарный vmdk, на хост Hyper-V и создаём там машину 1 поколения со схожими параметрами, нелишним будет указать MAC со старой машины – это критичная вещь, если работа с VM ведется через браузер, иначе чистить кеш браузера/кеш ARP у всех пользователей машины. В процессе создания машины указываем получившийся диск.

К счастью больше ничего делать не нужно.

Проверка

После того как машина загрузится хорошей вещью будет проверить свободную память:

free -m

Проверить загрузку машины, а именно пункт load average, напомню, что эта группа значений показывает загрузку за последние 1, 5, 15 минут соответственно, а цифра 1 – обозначает 100% загрузку CPU (при наличии 1 ядра, при 2 ядрах 100% это уже 2 и так далее; несложно посчитать загрузку – поделить данную цифру на количество ядер и умножить на 100%):

top

или

uptime

или

И соответственно по результатам оставить или же добавить ресурсов машине.

Источник: https://arny.ru/virtualization/perenos-virtualnoy-mashinyi-vmware-na-hyper-v/

Как переместить виртуальную машину Hyper-V 3.0

Добрый день уважаемые читатели блога, я продолжаю знакомить вас с виртуализацией на базе Microsoft Hyper-V 3.0 и сегодня мы рассмотрим, как переместить виртуальную машину, с одного хоста на другой, в идеале без простоев и без наличия централизованных утилит управления, по типу SCVMM 2012 R2 и без общего хранилища. Думаю для начинающих системных администраторов, это будет полезно.

live migration в Hyper-V

Перемещение виртуальной машины или как его еще называют live migration, появилась в рабочем виде только в Hyper-V 3.0 в операционной системе Windows Server 2012 R2. В данной версии его существенно улучшили и теперь он работает без общего хранилища и без кластера, от вас лишь в идеале потребуется гигабитное сетевое подключение, между участниками перемещения.

Хочу отметить, что основной фишкой live migration, является то, что виртуальная машина продолжает работать, нет простоя

Что переносится при live migration

Виртуальные машины
Виртуальные диски
Содержимое оперативной памяти
Состояние процессора

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

Требования live migration

Давайте определимся, что необходимо для успешного перемещения виртуальной машины на Hyper-V 3.0:

Логично, что нам нужно минимально два хоста виртуализации, первый это источник перемещения, а второй, хост назначения.
У хоста назначения, должно хватать ресурсов, чтобы принять виртуальную машину
Обязательное требование, это процессоры должны быть одного семейства, если у вас процессор intel, то перевезти на AMD у вас не получиться, такие же ограничения были и у vMotion Vmware
Сетевое подключение между хостами Hyper-V 3.0, желательно должно быть 1 гб/сек, можно даже под это дело выделить отдельную сетевую карту с другим VLAN ID.
В некоторых случаях виртуальные коммутаторы на обоих хостах должны называться одинаково, чтобы избежать ошибок перемещения.

И так на первом хосте, у меня есть виртуальная машина с именем dc7, ее я хочу переместить на другой хост Hyper-V. Для этого щелкаем по ней правым кликом и выбираем переместить.

первое окно мастера можно сразу пропускать, оно не несет ни какой полезности.

Далее у вас два варианта перемещения:

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

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

Далее вас спросят:

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

Далее задаем папку сохранения.

Все начинается процедура перемещения, если у вас не включена динамическая миграция, то вы можете получить ошибку 0x8009030E, посмотрите как она решается.

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

В диспетчере задач, можно про мониторить загрузку сети при перемещении.

Как видите в процессе живой миграции на хостах Hyper-V 3.0, без общего хранилища, нет ничего сложно, в принципе все понятно на интуитивном уровне и Microsoft, с каждым релизом упрощает жизнь системным администраторам.

Источник: http://pyatilistnik.org/kak-peremestit-virtualnuyu-mashinu-hyper-v-3-0/

Перенос физического сервера на гипервизор Citrix XenServer или “How to convert VHDX to VHD без заморочек”

09.09.2014 – 09:44

Поступила задача:

Есть удалённый физический сервер Windows Server 2008 R2 в другой стране, за 2000 км
Есть гипервизор Citrix XenServer 6.2.0
Необходимо провести конвертацию данного сервера на гипервизор

Необходимо сделать:

Конвертацию физического сервера можно сделать с помощью различных утилит
1. Citrix XenConvert, к сожалению, данный конвертер не определяет более 5 логических дисков. К сожалению, все попытки сделать копии разных физических машин, данный конвертер постоянно выпадал с ошибкой на 70% процесса. Каждый раз ошибки были разными. Видно, сказывается “бесплатность” гипервизора.
2. VMware vCenter Converter- ничего не могу сказать, знаю, что конвертация должна проходить сразу на гипервизор, что не позволяет рассматривать данный вариант
3. MS Disk2VHD – утилита, размером в 800Кб, которая может делать копии системы в форматах VHD и VHDX с включённой VSS. Максимальное кол-во определяемых дисков я не знаю, но определил все, которые не смог определить Citrix. Рекомендую!
После создания копии, её нужно загрузить в корпоративную сеть. Можно загрузить образ, размером в 100Гб, на FTP сервер с помощью клиента FileZilla. Данный клиент загрузит файл без потерь. Если же FTP нет, можно воспользоваться Torrent-ом. Инструкция.
Импортировать файл в Citrix. И тут у меня возникла проблема. Дело в том, что я не обратил внимание на галочку “Use VHDX” и создал образ в 100Гб в формате VHDX. К сожалению, данный формат не поддерживается Citrix-ом. Нужно конвертировать. Это не проблема, если у Вас установлен ещё один гипервизор – Hyper-V, где можно сконвертировать через консоль или PowerShell.Что делать, если этой платформы нет? Устанавливать и настраивать? Если нет лишнего сервера – это не тот вариант. Можно сделать конвертацию с помощью VirtualBox. Нужно установить VirtualBox на любую машину, я установил на свой рабочий ноутбук и запустить из папки, куда установлен VirtualBox, команду:vboxmanage clonehd filename.vhdx filename.vhd –format vhdДанная утилита поддерживает UNC пути, так что можно не копировать VHDX на рабочую машину и так далее.
Импортировать полученный VHD в Citrix XenServer, как виртуальную машину.

Источник: Server Fault
Описание утилиты: VBoxManage clonehd

Спасибо умным людям, которые решили проблему, которую можно было бы избежать.

Источник: http://www.unix.ck.ua/content/perenos-fizmcheskogo-servera-gipervizor-citrix-xenserver-ili-how-convert-vhdx-vhd-bez-zamoro

Параллельный мир: Сравниваем возможности виртуальных машин – «Хакер»

Содержание статьи

VMware ESXi
MS Hyper-V
OpenVZ
KVM
Xen
Заключение
Бесплатный XenServer
Links

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

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

Да и сегодня на десктопах нередко можно найти VMware Workstation и VMware Player. Последний появился как ответ MS Virtual PC и является бесплатной версией Workstation. Работает он из-под установленной ОС, то есть к промышленной среде не совсем подходит.

Для установки на «голое железо» предлагается VMware ESXi – самостоятельный продукт, являющийся основой для установки гостевых ОС, а совместно с VMware vSphere — средством для построения виртуальной инфраструктуры и управления виртуальными ресурсами (подробнее в статье «Виртуальная сфера», см. ][ 08.2010).

По сути, ESXi — это сильно урезанная версия Linux, содержащая гипервизор (VMkernel) и консоли управления: vCLI (vSphere CLI), PowerCLI (PowerShell интерфейс к vCLI), SSH и DCUI (Direct Console User Interface).

Ранее ESXi считался «младшим братом» в линейке продуктов VMware, ведь он представляет собой бесплатный и урезанный вариант ESX.

Но время ESX прошло, следующие версии VMware VSphere будут включать поддержку исключительно ESXi (предложено также его альтернативное название — VMware vSphere Hypervisor), а все преимущества ESX перед ESXi сошли на нет. Так что разработчики рекомендуют переходить на ESXi.

Главное отличие ESXi от ESX заключается в архитектуре. Основой ESX служит полноценная версия Linux, на которую можно устанавливать при необходимости свои приложения. Агенты VMware работают через COS (Console OS), то есть через дополнительный уровень. В итоге мы имеем больший размер дистрибутива: ~2 Гб по сравнению с 350 Мб у ESXi (на хард ставится всего 70Мб).

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

Дистрибутив можно записать на флэшку или вообще вшить в firmware сервера. Из-за некоторых особенностей официальный список совместимого оборудования у ESXi (clck.

ru/9xlp) меньше, чем у ESX, который поддерживается и старыми серверами, но со временем он увеличится. Кроме того, добровольцами создан неофициальный список компьютеров ESXi Whitebox HCL (clck.ru/9xnD), на которых работает VMware ESXi.

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

Продукт от VMware отличает поддержка большого количества гостевых ОС. Здесь полный фарш — Windows, Linux, Solaris, FreeBSD, Netware и многие другие, весь список доступен на сайте.

Функциональность последних релизов ESXi уже «подтянули» под возможности ESX — появилась интеграция с Active Directory (любая учетная запись будет проверяться в каталоге), функции расширенного управления памятью (неиспользованные ресурсы освобождаются), совместная работа с системами хранения данных VMware vStorage VMFS/Storage VMotion и SAN, настройка приоритетов трафика, технология безопасности VMsafe Security API. Гибкое распределение ресурсов позволяет «на горячую» добавить CPU, ОЗУ, жесткий диск (в том числе и изменить размер текущего без перезагрузки).

Установка дистрибутива на голое железо очень проста (стандартный вариант с привода или через PXE), к тому же начиная с версии 4.1 поддерживаются сценарии, позволяющие автоматизировать процесс инсталляции ПО, настройку сети и подключения к vCenter Server. Через VSphere API интегрировано управление резервного копирования ESXi.

Немаловажно наличие специального конвертера VMware vCenter Converter (vmware.com/products/datacentervirtualization/converter), позволяющего использовать в ESXi образы MS Virtual Server, Virtual PC, Hyper-V, а также физические серверы и образы дисковых разделов, созданных такими программами как Acronis True Image, Norton Ghost и другими.

Кроме этого, помочь в развертывании ESXi может и бесплатный веб-сервис VMware Go (go.vmware.com), позволяющий протестировать физический сервер на совместимость, установить ESXi и создать новые VM.

Технология виртуализации от MS, финальная версия которой выпущена летом 2008 года. С выходом Win2k8R2 Hyper-V получил новые возможности — Live Migration, динамическая память, улучшены ряд инструментов и поддержка оборудования.

Hyper-V построен по принципу гипервизора с микроядром и напрямую «общается» с оборудованием сервера на Ring-1. Это уменьшает расходы, благодаря чему достигается высокая скорость работы.

Предлагается в двух вариантах — как роль Windows Server 2k8/R2 (доступна в полном варианте и Server Core) или как отдельное решение для установки на «голое железо» — MS Hyper-V Server 2008 R2 (microsoft.com/hyper-v-server).

Последний распространяется бесплатно (не требует Client Access License), лицензия понадобится лишь для гостевых Windows. По сути, это урезанный вариант Server Core, в котором установлена одна роль (без возможности изменения) и ограничены инструменты управления.

Кроме лицензии, между разными вариантами Hyper-V есть и другие отличия, но в бесплатном варианте доступно все необходимое для построения сервера виртуализации. Это поддержка технологии Live Migration, консолидация серверов и кластеризация узлов.

Сервер, на который устанавливается MS Hyper-V Server, может иметь ОЗУ в 1 Тб и до 8 CPU, чего вполне достаточно для задач небольшой и средней организации.
Официально поддерживаются 32- и 64-битные версии Windows XP SP3, Vista SP2/2k3 SP1/2k8 и Linux (SLES и RHEL).

Но в интернете можно найти десяток руководств, в которых описана успешная эксплуатация других версий *nix — Ubuntu, FreeBSD и так далее. Для установки рекомендуется выбирать дистрибутивы Linux с ядром 2.6.32+, в котором добавлена поддержка Hyper-V (LinuxIC, распространяется MS под GPL).

Правда, только гостевые Win2k8 могут быть сконфигурированы с 4 vCPU.

Для установки MS Hyper-V Server потребуется компьютер с x64 CPU, поддерживающий технологии Intel VT или AMD-V, и минимум 1 Гб RAM.

Для управления большими массивами виртуальных серверов MS предлагает отдельный продукт System Center Virtual Machine Manager 2008 (SCVMM 2008), имеющий инструменты для P2V(Physical to Virtual) и V2V-конвертирования серверов (с VMware).

Опять же, в списке поддерживаемых для P2V только Win. Поэтому, чтобы перенести свой сервак, работающий на Linux, придется выбрать длинный путь: VMware vCenter Converter .. ESXi .. SCVMM .. Hyper-V.

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

В этом случае безопасней установить систему вчистую, а затем перенести данные из бэкапа. Вместо SCVMM в этой связке можно использовать бесплатный VMDK2VHD (vmtoolkit.com/files), Citrix XenConvert, Quest vConverter (quest.com/vconverter).

OpenVZ (OpenVZ.org) представляет собой расширение к ядру Linux, реализующее концепцию виртуального окружения (Virtual Environments). Ядро базового дистрибутива одно на всех, виртуализация производится на уровне экземпляров ОС.

Именно поэтому в качестве гостевых можно использовать только Linux.
Конечно, это несколько сужает сферу его применения.

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

Такой подход практически не сказывается на производительности (накладные расходы не выше 1-3%). Зато в ресурсах админ практически не ограничен — до 64 Гб RAM, 4096 CPU и так далее.

При установке создается виртуальное сетевое устройство (venet), которое дает возможность задать для каждой VM свои сетевые настройки (IP и правила маршрутизации).

Собственно, отсутствие каких-либо ограничений на ресурсы (кроме тех ограничений, которые связаны с возможностями физического сервера) делают OpenVZ популярным у хостеров, да и у админов, юзающих Linux.

Гостевые ОС обычно разворачиваются при помощи подготовленных контейнеров ОС. Администратор указывает доступные ресурсы и дисковые квоты (по inodes и/или объему), создавая шаблоны, которые и становятся основой VM.

Такой подход очень упрощает процесс при создании большого количества однотипных VM. Причем контейнеры используются и при миграции (Checkpointing), когда замороженное состояние переносится на другой физический сервер.

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

Проект предлагает несколько десятков шаблонов дистрибутивов (download.openvz.org/contrib/template/precreated), а поискав в интернете можно найти и дополнительные варианты.

Управление OpenVZ производится при помощи пакета утилит vzctl (vzlist, vzmigrate, vzcalc, vzcfgvalidate, vzmemcheck, vzcpucheck, vzpid, vzsplit и других).

Для удобства админы создают скрипты, хотя сегодня доступен ряд интерфейсов, делающих процесс управления OpenVZ, KVM и Xen (о них ниже) более наглядным — WebVZ (webvz.sf.

net), Kloxo (она используется в спецдистрибутиве Proxmox VE) и HyperVM.

Традиционно OpenVZ является «домашней» системой виртуализации для дистрибутивов, базирующихся на Debian.

Технология виртуализации KVM (Kernel-based Virtual Machine) продвигается компанией RedHat и является «основной» в этом дистрибутиве и его клонах. Требует поддержку аппаратной виртуализации Intel VT или AMD V.

Это означает, что KVM может использоваться далеко не на каждом компьютере: старые и некоторые из новых CPU (например, Intel Atom) не подойдут. В принципе, если оборудование закупается под задачу — это не проблема.

Проверить очень просто:

$ egrep '^fl ags.*(vmx|svm)' /proc/cpuinfo

Распространяется он по лицензии GNU GPL, компании RedHаt и Novell предоставляют коммерческую поддержку.
Реализован в виде базового модуля ядра (kvm.ko) и userspace.

Последний представляет собой модифицированный QEMU (qemu.org), предназначенный для эмуляции аппаратного обеспечения. В зависимости от типа CPU грузится и специфический модуль — kvm-amd.ko или kvm-intel.ko. Для настройки виртуальных машин используется псевдоустройство /dev/kvm.

Все инструкции выполняются в специальном гостевом режиме, в полностью изолированном от системы и друг от друга адресном пространстве. Ввод-вывод сетевых, блочных и balloon (работа с памятью) устройств реализован через драйвер Virtio, остальные в userspace.

Накладные расходы выше, чем у OpenVZ, и, в зависимости от задач, могут быть до 20%.

Но у KVM есть несомненный плюс — в качестве гостевых можно запускать Linux, *BSD, Windows, Solaris, Mac OS X и ряд других ОС.

Гостевые системы ограничены фактически ресурсами сервера, каждая может иметь до 16 vCPU (некоторые ОС, вроде Win XP, предварительно следует специфически подготовить).

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

Удобно, что KVM поддерживает vmdk-образы, созданные в VMWare, процесс переноса очень прост и хорошо описан в соответствующем HOWTO (clck.ru/9xlp). Учитывая, что KVM включен в состав ядра Linux начиная с версии 2.6.20 (раньше, чем другие системы виртуализации), проблем с установкой ни для одного из дистрибутивов нет.

В KVM поддерживается savevm/loadvm, offline и «живая» миграция виртуальных машин (последние — через команды migrate*).

Основным условием успешного переброса хоста является идентичность оборудования (тип CPU) и настроек гостевой системы, в том числе и пути к файлам образов. Хотя в некоторых случаях можно перенести ОС и без полного соответствия, но это потребует больше трудов и увеличивает вероятность ошибки. Гостевые ОС легко клонируются: один раз создав шаблон, его легко размножить.

Конвертирование P2V возможно двумя способами.

Первый через dd, как описано в документации QEMU, но стандартной такую операцию назвать нельзя.
Второй — применить VMWare Converter.

Так как KVM основан на QEMU (оба проекта тесно связаны друг с другом), то принципы управления (в частности, создания образов) остались те же. Для загрузки новой гостевой ОС через /dev/kvm используется специальная утилита kvm.

Управление осуществляется при помощи фронт-энда virt-manager, разработанного RedHat, или утилит командной строки qemu* и kvm. Чаще всего админы для удобства используют скрипты (на сайте проекта можно найти несколько заготовок).

Также доступны и интерфейсы: кроме тех о которых говорилось выше, это Karesansui (Xen/KVM), Symbolic, ConVirt (Xen/KVM), Ganeti (Xen/KVM).

Популярный гипервизор начал свой путь в конце 90-х, в недрах компьютерной лаборатории Кембриджского университета, и был доступен по GNU GPL. Первый публичный релиз вышел в 2007 году.

Со временем была образована компания XenSource, выкупленная чуть позже Citrix, который создал на его основе свой Citrix XenServer (CentOS + Xen). Кроме того, гипервизор Xen используется в Oracle VM.

Но изначально все новшества появляются в Xen, и только через некоторое время — в сторонних продуктах.

Относительно недавно проект начал разработку платформы облачных вычислений Xen Cloud Platform.

Xen можно назвать универсальным, так как помимо поддержки полной (аппаратной) виртуализации (HVM, Hardware Virtual Machine) реализован режим паравиртуализации (PV).

А значит, мы можем запустить его на сервере, не имеющем CPU с Intel-VT и AMD-V, но для этого требуется модифицированная версия ОС. К слову, именно разработчики Xen ввели в свет термин «паравиртуализация».

Код гипервизора и сопутствующих модулей сделан переносимым, в итоге Xen поддерживает несколько архитектур: x86, x86_64, Itanium, Power PC и ARM, хостовые ОС — Linux, NetBSD и FreeBSD. Первые релизы гипервизора были внедрены и в WinXP, однако конечное решение так и осталось экспериментом.

В качестве гостевых ОС можно установить Linux, NetBSD, FreeBSD, Solaris и Windows. Производительность гостевых систем близка к работе непосредственно на железе, максимальные потери — до 8%.

Поддерживаются Live Migration, изменение размеров диска, использование гостевой ОС видеокарты напрямую, задействование неиспользуемой памяти гостевых систем, синхронизация состояния VM между серверами (Remus Fault Tolerance), доступ к USB-устройствам.

Процессы гостевых ОС полностью изолированы друг от друга, не могут использовать привилегированные инструкции (такие обращения отправляются непосредственно гипервизору).

В версии 4.1 физический сервер может иметь > 255 CPU, 1 Тб RAM, а гостевая система — до 128 vCPU; доработано управление пулами CPU и теперь каждый пул может работать со своим планировщиком. В ядре vanilla Linux Xen «поселился» с версии 2.6.37, хотя в некоторых дистрибутивах Linux он уже давно поддерживался «из коробки».

Управление производится при помощи пакетов xen-utils, xen-tools, плюс доступно несколько интерфейсов. Кроме тех, о которых говорилось выше, сюда можно добавить virt-manager, AQEMU, OpenQRM, Xen Orchestra, Zentific, xnCORE и некоторые другие.

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

Обычно все упирается в дисковую подсистему.

Если планируется управление несколькими серверами, то при недостатке средств в первую очередь следует присмотреться к OpenSourceрешениям, имеющим многочисленные панели управления.

XenServer (текущая версия 5.6.1) в чем-то похож на VMware ESXi. Предоставляется он бесплатно, и его можно использовать без ограничений. Но для централизованного управления фермой серверов предлагается XenCenter, продаваемый под собственнической лицензией Citrix. Функционально XenServer — очень мощный инструмент.

Админ получает неограниченное количество серверов и виртуальных машин; Live Motion; непрерывное обслуживание при условии, что ресурсы нескольких серверов объединены в пул; контроль доступа на основе ролей (RBAC) и интеграцию с Active Directory; динамическое управление памятью, позволяющее добавить RAM в VM без перезагрузки.

Рабочая нагрузка динамически перераспределяется не только между виртуальными, но и между физическими серверами, что существенно упрощает управление. Спроектирован с учетом требований по предоставлению высокого уровня доступности системы (High Availability).

Рабочую ОС, установленную на любом физическом сервере, можно легко конвертировать в виртуальную систему.

Умеет работать с основными системами хранения данных (локальный диск, NAS, SAN и так далее). Экспериментально может работать с образами дисков в форматах VMWare VMDK, MS VHD, VDI, WIM.

Официально в качестве гостевых систем поддерживаются все версии Windows, начиная от Win2k SP4, Linux (SLES, RHEL/CentOS, Oracle EL, Solaris, Debian).

Гостевая система поддерживает до 64 логических процессоров, 256 Гб оперативной памяти и 16 сетевых адаптеров на хост.

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

Источник: https://xakep.ru/2011/11/07/57429/

Перенос Windows 2008 server на Citrix XenServer

Вводная.

Есть у меня сервер, на котором висит MsSQL, Tomcat и еще несколько сервисов. Железка простенькая, но надежная. HP dl160 g6. Работает под вынь 2008. Запустили его давно, примерно 4 года назад. За это время пришлось завести еще один серв, на котором висит VPN сервер и пара сайтов. В роли второго сервера выступил обычный дестоп под linux.

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

Появилась идея виртуализировать оба сервера, и установив на HP Citrix XenServer, крутить все это на нем.

С XenServer я работаю уже года 3, но переносить живую винду с реального сервера в виртуалку еще ни разу не приходилось.

Как это было.

Перенос системы в вирталку делается просто. Сперва нужно установить XenConvert. После запуска, программа предлагает сконвертировать ОС в виртуальную систему (т.е. создать образ диска, и конфигурацию для загрузки на вирт машине).

На выбор предлагает несколько вариантов. Не помню все по списку, но примерно все выглядит так — или в VHD файл, или на XenServer напрямую. Разница в том, что во первом варианте, сперва создаешь файл, потом файл импортируешь в XenServer через XenCenter (это программа управления сервером по сети), во втором варианте, система конвертируется, и напрямую заливается на XenServer по сети.

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

Диск объемом примерно 300 гиг, конвертируется больше 6 часов, причем скорость процесса зависит не от скорости диска, а от каких то других факторов.

После того, как система сконвиртировалась в VHD файл, я установил на сервер XenServer 6.2, и думал, что осталось совсем немного — импортировать полученный файл на сервер. Но не тут то было. Процесс импорта обрывался с ошибкой «import failed», без объяснения причин.

Спева конечно погуглил, но ничего путного не нашел. Затем просмотрев ченжлог для XenServer 6.2 выснил список обнаруженных багов и какие патчи можно попробовать поставить. В процессе выяснилось, что через через меню в XenCenter патчи ставиться не хотят. Пришлось ставить в ручную. Сперва поставил сервис пак.

Скачать его можно отсюда: http://downloadns.citrix.com.edgesuite.net/8707/XS62ESP1.zip

Перед установкой рекомендую ознакомиться с release notes http://support.citrix.com/article/CTX139789

Архив сервис пака состоит из двух частей — непосредственно из патча, и архива с исходниками. Для установки на сервер нужен только файл патча XS62ESP1.xsupdate. Что бы его поставить нужно закинуть его на сервер, а далее сделать.

В ответ программа выдаст идентификтор патча (иначе его можно посмотреть по команде xe patch-list )
Далее нужно загруженный патч применить.

После чего сервер нужно перезагрузить.

Но как выяснилось позже, это было не обязательно. Дело в том, что при импорте файла с виртуалкой, мастер спрашивает о ip адресе сервера на который нужно импортировать. Я сперва выбирал DHCP, но как оказалось, в этом и была проблема. После того, как указал адрес статически, процесс импорта все же запустился.

После переноса системы в виртуалку нужно обязательно поставить XenServer Tools. У меня почему то они не встали с первого раза, но это уже совсем другая история.

Еще в процессе переноса системы обнаружил странный баг. При загрузке, сервер выдавал ошибку «BNC Not Responding», при этом в начале загрузки не отображалась версия BIOS. А при входе в BIOS, в разделе настройки iLO неотображались настройки ip адреса, вместо них было написано «BNC Not Responding».

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

Источник: https://pustovoi.ru/2014/1970

Миграция виртуальной машины 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

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

В веб-консоли oVirt выполняем экспорт виртуальной в формат OVA
Копируем OVA-шаблон ВМ на хост Hyper-V, распаковываем OVA и с помощью qemu-img конвертируем диск формата QCOW2 в формат VHDX
Создаём в 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:TempKOM-HPVSP6a7ced92-57ae-4a07-b458-e45c2ccf38e0”

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

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

qemu-img convert -O vhdx -o subformat=dynamic “D:TempKOM-HPVSP6a7ced92-57ae-4a07-b458-e45c2ccf38e0” “D:TempKOM-HPVSPDisk1.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. Таким образом, общий план действий будет следующим:

В веб-консоли oVirt выполняем экспорт виртуальной в Export Domain
Находим в хранилище Export Domain диск и утилитой qemu-img конвертируем его в VHDX
Создаём в 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.

Похожее

Источник: https://blog.it-kb.ru/2018/07/31/virtual-machine-migrating-from-ovirt-4-2-to-hyper-v-via-export-to-ova-or-export-domain-and-converting-qcow2-to-vhdx/