Конвертировать vmware в kvm

Обновлено: 04.07.2024

virt-v2v — утилита конвертации виртуальных машин для их запуска с помощью гипервизора KVM. Позволяет конвертировать виртуальные машины, созданные при помощи гипервизоров VMware, Xen, Hyper-V и др.

Установка virt-v2v в CentOS 7 выполняется командой:

Полная документация virt-v2v доступна из консоли:

Режимы работы

Режим работы virt-v2v определяется параметрами:

-i — тип входных данных;
-o — тип выходных данных.

Типы входных данных:

-i disk <имя виртуального диска> — виртуальный диск из локального хранилища;
-i libvirt <наименование или идентификатор виртуальной машины> — виртуальный диск виртуальной машины экспортируется из libvirt. В libvirt виртуальная машина определяется по указанному наименованию или идентификатору. Используется по умолчанию. Параметр -ic позволяет выбрать конкретный гипервизор, с которым работает libvirt;
-i libvirtxml <XML-описание виртуальной машины> — виртуальный диск виртуальной машины с указанным XML-описанием libvirt;
-i ova — виртуальный диск виртуальной машины на базе VMware в формате ova;
-i vmx — виртуальный диск виртуальной машины на базе VMware в формате wmx.

Типы выходных данных:

-o glance — виртуальный диск записывается для OpenStack Glance;
-o libvirt — виртуальный диск для libvirt. Libvirt подключает диск к локальному или удалённому гипервизору KVM. Параметр -oc позволяет выбрать конкретный экспортирующий гипервизор;
-o local -os /dir — виртуальный диск с конфигурационным файлом libvirt записываются в директорию /dir, которую определяет параметр -os;
-o qemu — виртуальный диск записывается локально, а также скрипт оболочки для загрузки виртуальной машины напрямую в QEMU;
-o rhv — виртуальный диск записывается для RHV / oVirt.

Конвертация виртуальных машин для импорта в VMmanager

Утилита virt-v2v может быть использована в процессе импорта виртуальной машины в VMmanager. Подробнее см. в статье Импорт виртуальных машин.

Для импорта виртуального диска виртуальной машины в VMmanager необходимо указывать тип выходных данных -o local -os /dir, где /dir — директория для записи сконвертированной виртуальной машины.

Я уже упоминал про то, что мы, в Nutanix, можем легко мигрировать виртуальные машины из VMware vSphere в среду KVM, без необходимости заново создавать их. Просто переносом файла виртуального диска этой виртуальной машины и запуском новой, с использованием содержимого этого виртуального диска, но уже из KVM. Такая простая процедура может помочь при миграции из платного VMware в бесплатный и свободный KVM, так как нет необходимости заново создавать виртуальную машину, инсталлировать OS, переносить приложения, и так далее. В результате миграция занимает минуты, вместо часов, и может даже быть автоматизирована.

Я даже писал тут краткий гайд по такому переносу. Однако гайд получился уж совсем краткий. И сегодня я публикую перевод подготовленного в Nutanix подробного пошагового плана процесса переноса виртуальных машин из vSphere в KVM, на примере VM с Windows.

1. Подготовимся

Перед тем, как начать, все подготовим:

Выберите хост ESXi

Щелкните закладку Configuration
Щелкните Storage
Щелкните Add Storage…

Выберите вариант Network File System

Введите IP address любого CVM в кластере KVM Nutanix
Введите имя контейнера, помните про первый ‘/’ и про то, что имя контейнера регистрозависимое
Имя создаваемого датастора сейчас не имеет значения, мы используем этот датастор только для миграции!

Проверим, что все в summary выглядит хорошо и щелкнем Finish

Новый датастор появится в списке Datastores

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

Щелкните правой клавишей и выберите Browse Datastore…

Вы увидите вашу виртуальную машину, у нас это Win7-Demo-Copy

Щелкните по папке VM для того, чтобы выделить ее

С выбранной папкой щелкните иконку Move на тулбаре (листок с зеленой стрелкой на нем)

Выберите в качестве цели датастор, который мы смонтировали перед этим, в нашем случае он называется KVM-Datastore
Щелкните на ‘/’
Щелкните кнопку Move

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

Заметьте, что виртуальная машина все еще отображается в инвентори ESXi, вы можете удалить ее оттуда

4. Импортируем VM в KVM

Выберите в выпадающем слева меню пункт VM
Щелкните + Create VM

Создайте новую VM с тем же виртуальным железом, что и у скопированной:

Выберите CLONE FROM NDFS FILE
Измените тип шины на IDE
Щелкните на поле path, введите ‘/’ и вы увидите возможные пути. Найдите VM и выберите файл с именем –flat.vmdk

Щелкните Add

Вернувшись в панель выбора virtual hardware для VM, перейдите в строку CDROM, и кликните на значок карандаша

Выберите CLONE FROM NDFS FILE
Щелкните на поле path, введите ‘/’ и вы увидите возможные пути. Найдите ISO-файл с драйверами Virtio, который вы записали в контейнер
Щелкните Update

Щелкните + New NIC и назначьте сеть для VM (о настройке VLAN мы не говорим тут, считаем, что вы ее уже настроили)

Щелкните Save

5. Сконфигурируем VM

Найдите VM в инвентори
Щелкните Power On

VM начинает загружаться

Зайдите с правами локального админа

Запустите Device Manager

Вы увидите несколько неопознанных устройств

Щелкните право кнопкой на Ethernet Controller

Выберите Update Driver Software…

Выберите Browse my computer for driver software

Перейдите на CD drive, на который смонтирован ваш ISO с драйверами Virtio, щелкните OK

Диск будет просканирован и обнаружены нужные драйвера

Поставьте отметку в Always trust software…
Щелкните Install

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

6. Преобразуем формат дисков

Наконец, преобразуем формат диска из IDE в SCSI. Это повышае производительность операций с дисками и уменьшает загрузку процессора.

Подключитесь к любому CVM в кластере KVM Nutanix Cluster использую логин: nutanix и пароль: nutanix/4u

Ниже скринoшот для примера.

Отметьте, что значение vmdisk_uuid можно скопировать и вставить при использовании PuTTy или Apple’s Terminal.

Вернитесь в Prism

Найдите вашу VM в инвентори
Щелкните Update

В списке виртуального железа появится еще один диск

Найдите диск IDE по его описанию, полное описание появится, когда вы остановите мышь над соответствующей строкой

Щелкните X для того, чтобы удалить его

Щелкните Yes

Щелкните Save

Теперь включим виртуальную машину

Все готово. Мы перенесли и запустили виртуальную машину с Windows из VMware vSphere в среду Nutanix KVM.

Похожее

Запись опубликована 11/06/2015 автором romx в рубрике techtalk с метками acropolis, ESXi, KVM, migration, nutanix.

Как перенести VM из VMware ESXi в Nutanix KVM? : 27 комментариев

И почему вы считаете, что Nutanix не контрибьютит в комьюнити код? Только потому, что его нет в списке members Linux Foundation? Не забыайте, что free/open software это не только Linux, я об этом уже писал в комментарии выше.

> Тут дело совершенно не в юриспруденции ведь. Используюя свободный софт — я могу его изменить в своих целях в случае необходимости

> что дает мне открытость Nutanix по сравнению с закрытостью Hyper-V именно с точки зрения открытости\закрытости?

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

> Поставив в пример Yahoo и Amazon, вы забыли упомянуть что в этих примерах компании используют «допиленные» решения внутри себя, но не продают эти допиленные решения конечным заказчикам.

P.S.: И это не считая количества коммитов от соответсвующих компаний в соответсвующие проекты.

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

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

Поэтому вопрос, где открытость и свободность (в любой удобной вам формулировке) у Nutanix для меня по-прежнему открыт.

Роман,
Раз уж вы не хотите отвечать на мой прошлый комментарий, то скажите считаете ли вы, что, например, компании Microsoft и VMware являются настолько же «свободными и открытыми», как и Nutanix?
Они так же используют некоторые open source компоненты в своих решениях (SLES и PostgreSQL у VMware в большинстве appliance, OS компоненты в ESXi (пункт 1.9 в EULA VMware), Linux Integration Components, драйвера у Microsoft и другие), а, главное, схожими c Nutanix правами и ограничениями в разрезе использования продуктов конечными пользователями.

Я правда некомпетентен спорить, извините. Это даже не беря во внимание, что мне тема не очень интересна, извинити :)

Неплохо бы еще деинталлировать VMware Tools и удалить зомби Ethernet адаптер, который останется после миграции.

>Нет, именно в ней. Понятие «открытый», «свободный» и «с открытым исходным кодом» являются юридически определенными, так, как это сформулировано в их лицензиях. Вы же пытаетесь трактовать это так, как вам хочется. Так мы далеко зайдем. Начните, правда что, с чтения прилинкованных статей на Википедии и Либертариуме, просто чтобы мы были хотя бы на одной платформе в дискуссии.

Код был под свободоной лицензией пока он распространялся под ней, то есть ровно до того момента, как попал в Nutanix и был изменен. Так как дальше Nutanix этот код не распространяет, то и говорить особо не о чем )

>Что значит «не продают»? Они продают результаты их работы, точно также, как и Nutanix. Yahoo! или AWS продает свои сервисы, построенные на базе открытого ПО. Nutanix тоже продает свои сервисы, реализованные на открытом ПО. Разница лишь в том, что физический сервер у AWS стоит у него в датацентре, а в случае Nutanix — в вашем.

Ждал именно такого ответа ) Только вот когда мы пользуемся сервисами вышеперечисленных компаний как услугой, в случае же с Nutanix мы приобретаем программно-аппаратный комплекс в пожизненное пользование.

> Код был под свободоной лицензией пока он распространялся под ней, то есть ровно до того момента, как попал в Nutanix и был изменен. Так как дальше Nutanix этот код не распространяет, то и говорить особо не о чем )

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

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

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

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

Вот сегодняшнее письмо:

On general request, here’s a summary how employees, partners and external users can have access to the Nutanix Community Edition.

Many thanks and kind regards,
Jan

Есть, осталось только дождаться, когда всем инвайты или что там у вас, у кастомеров.
У эмплоев вот так это выглядит, например:

Успешно перенес виртуалку с CentOS 7.3 (потребовалось через dracut включить модули virtio*).
Виртуалка размещена в Storage Container VMs (который экспортировался по NFS хостам ESXi)
Как смувить перенесенную виртуалку в другой контейнер, например, в default ?

Привет. Статья-то совсем старая. У вас не перенесся почему-то виртуальный диск? Сейчас то же самое делается куда проще, через импорт в Image Services.

А можно подробнее про импорт в Image Service?

Виртуалка нормально перенеслась, со всеми своими дисками. Лежит в контейнере VMs (в папке .acropolis). Я хочу виртуалку смувить в контейнер default-XXXXXX, а контейнер VMs удалить.

Главный претендент на замену коммерческой системы виртуализации VMware – это гипервизор KVM, который поддерживается современными ядрами Linux. Любой современный дистрибутив Linux в той или иной мере позволит воспользоваться системой виртуализации KVM. Передо мной как-то поставили задачу: можно ли запустить или конвертировать одну гостевую операционную систему из одной системы виртуализации в другую?

В KVM активно используется для построения виртуальной среды такой компонент как QEMU. QEMU умеет работать с файлами vmdk или конвертировать их в свой формат. Файлы vmdk представляют собой виртуальные жёсткие диски виртуальных машин VMware, которые можно напрямую использовать в QEMU НО:

Поддерживаются только образы VMware 3, 4 и 6 версии.
В VMware тип виртуального диска должен быть: 0 (single growable virtual disk) или 2 (preallocated virtual disk) или нужно получить из существующего виртуального диска требуемый с помощью vmware-vdiskmanager, что занимает определённое время, зависящее от размера виртуального диска.
Конвертация конфигурации виртуализированного аппаратного обеспечения из одного формата (*.vmx) в другой в полностью автоматическом режиме невозможна. Требуется постоянный контроль человека и ручные правки.
Для тех кто использует virt-manager для работы с KVM/QEMU есть инструмент vmware2libvirt, который обладает массой ограничений: находит только первый сетевой интерфейс, первый жёсткий диск, захардкорджено использование 1 CPU, нельзя использовать любые vmware-специфичные вещи для гостя.

Для перехода из одной системы виртуализации в другую настоятельно рекомендуется в гостевых виртуальных машинах с MS Windows Server провести мероприятия:

Удалить установленные VMware Tools, которые оптимизируют работу виртуальной машины в среде VMware. Перезагрузиться.
Из-за невозможности точь-в-точь воссоздать эмулируемое аппаратное обеспечение, системы MS Windows болезненно реагируют на смену аппаратуры и Plug-n-Play identifier (PnP-ID). Вполне ожидаемый результат будет Экран Смерти (Blue Screen of Death) с кодом ошибки 0x0000007B. Для избежания проблем рекомендуется для виртуальных машин с MS Windows перейти на использование интерфейса работы с дисками IDE через процедуру описанной на VMware to Proxmox VE (KVM). Перезагрузиться.
Если переход с VMware на KVM удался, то можно оптимизировать работу MS Windows через установку драйверов virtio.

Вывод.
Все вышеперечисленные ограничения и возможные проблемы, дают право говорить, что полуавтоматическое использование существующих образов-дисков vmdk с установленной внутри MS Windows Server через гипервизор KVM возможен, но носит лабораторный и исследовательский характер. Использование такой гетерогенной системы из разных систем виртуализации на производстве будет очень проблематичным и без каких-либо гарантий в будущем.

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

Что нового в бесплатной системе виртуализации Proxmox VE 4 на базе KVM/QEMU ?

OS: "Linux Debian 9", "Linux Ubuntu 16 LTS", "VMware ESXi v5/6".
Application: qemu-img, vmkfstools.

Задача: мигрировать работающую в среде виртуализации "Linux Kernel-based Virtual Machine (KVM/Qemu-KVM)" виртуальную машину на платформу "VMware ESXi v6/6.5", как она есть, монолитным виртуальным диском. Будем считать, что внутри виртуальной машины исполняется достаточно современная OS "Linux" с типовым набором драйверов "паравиртуальных" устройств ввода-вывода, и это сильно упрощает миграцию, избавляя нас от необходимости какой-либо предварительной подготовки "гостевой системы".

Сразу скажу, что подавляющая масса советов и даже развёрнутых инструкций, описывающих муторный процесс миграции от KVM к "VMware ESXi" путём двухэтапной конвертации: вначале в VMDK(v4/v6)-формат, совместимый с "VMware Workstation/Fusion/Server", а потом в формат, якобы с дополнительными описаниями структуры, удовлетворяющий требованиям "VMware ESXi" - неверны на уровне понимания сути устройства компонентов ввода-вывода систем виртуализации.

Развеивая миф о сложностях конвертации, по (большому) секрету скажу, что в современном "VMware ESXi v5/6" виртуальные диски типов "Raw/Thick/Thin" на самом деле представляют собой последовательность данных, полностью соответствующую виду, в котором таковые находятся на "реальных" физических (IDE/AHCI/SCSI/SAS) или блочных (RAID/LVM) устройствах - разница лишь в способах указания на ресурс, организации (схлопывания) пустот и выделения дополнительного места на несущей файловой системе для "not-preallocated"-формата.

То есть, если исходный виртуальный диск в среде виртуализации Qemu-KVM представляет собой LVM-том (что является наиболее скорострельным с точки зрения производительности и предпочтительным в эксплуатации нагруженного сервиса) или RAW-файл, то "конвертация" сводится к "по-байтному" копированию его содержимого на целевую несущую файловую систему "VMware ESXi" и создания там для него простейшего текстового файла-описания. А если ваша виртуальная машина выросла из тестового стенда, где принято хранить данные в сжатых QCOW2, VDI, VHD или VMDK, то как раз пришло время избавиться от переживаний за исчерпывающееся на СХД свободное место, перейдя в стан специалистов умеющих считать и планировать.

Итак, приступим, разумеется рассчитав заранее примерное время простоя сервиса (прикинув скорость записи на диск для возможной предварительной конвертации из "сжатого" формата в RAW и передачи данных по сети на целевую систему виртуализации).

Подготовка на стороне "VMware".

Очень полезно в оснастке "VMware vCenter/vSphere" системы виртуализации заранее создать заготовку виртуальной машины, пока без подключённых HDD, чтобы сформировать структуру директорий и файлов, к которой в дальнейшем будет присовокуплён полученный после конвертации "диск" - иначе, если, например, мы вначале создадим директорию "./example.vm" и укажем таковую как месторасположение виртуального HDD, "VMware vCenter/vSphere" всё таки создаст рядом ещё одну директорию вида "./example.vm_1" для размещения там конфигурационных файлов, что в общем неудобно.

Для начала должно получится что-то вроде этого:

. 204 . example.vm-xxxxxxxx.hlog
. 0 . example.vm.vmsd
. 1.5K . example.vm.vmx

Подготовка на стороне Qemu-KVM.

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

Id Name State
------------------------
2 one.vm running
5 two.vm running
.
- example.vm shut off

Конвертирование "сжатого" или "динамического" виртуального диска в монолитный последовательный RAW-формат.

Лично я всегда стараюсь размещать виртуальные диски на носителях с минимальным количеством прослоек между системой виртуализации и аппаратурой - в случае с Qemu-KVM это LVM-тома. Как вариант допустимо применение RAW-файлов в оптимизированной файловой системе. Всё остальное ниже планки, разделяющее тестовые и производственные среды. Вполне возможно, что перед переходом на "VMware ESXi" придётся сконвертировать данные из QCOW, VDI, VHD или VMDK в "сырой" RAW-формат:

Можно полюбопытствовать параметрами полученного RAW-файла и сопоставить его размер с исходным "сжатым" или "динамическим", как минимум удостоверившись, что количество байт в них не отличается:

file format: qcow2
virtual size: 64G (68719476736 bytes)
disk size: 4.0G
. file format: raw
virtual size: 64G (68719476736 bytes)
disk size: 3.9G
.

О "прореженных" или "схлопываемых" файлах ("sparse files").

Кстати, обращаю внимание заметивших разбег между "virtual" и "disk size" в выводе выше на то, что практически все современные файловые системы в Linux поддерживают "схлопывание пустот" ("zero bytes") и занимаемое на несущем диске файлом количество байт наверняка будет меньше его условного (максимального) размера.

Например, в традиционном листинге нам показывают "условный" размер файла:

А вот явно запросив размер занятого места мы увидим, что на диске хранится гораздо меньше байт:

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

В общем, это не имеет отношения к рассматриваемой задаче миграции, но для понимания картины в целом может быть полезно. И ещё, для энтузиастов даю подсказку: утилита "rsync" с ключом "--sparse" умеет экономно копировать большие файлы, пропуская "zero bytes"-области.

Копирование RAW-данных виртуального диска в файловую систему "VMware ESXi".

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

LVM-том копируем, пропустив поток данных через конвейер (pipe), завёрнутый в SSH-туннель:

Применительно к RAW-файлу копирование проще осуществить посредством утилиты SCP из пакета SSH-приложений:

Ну а ценители изящного могут экономно передать большой "разрежённый" файл с помощью утилиты "rsync" (пусть это на сладкое останется).

Создание и применение файла-дискриптора (описания) виртуального RAW-диска "VMware ESXi".

Всё, что требуется "VMware" для применения полученного набора RAW-данных в качестве виртуального диска - так это маленький текстовый файл-дискриптор с описанием структуры данных и параметров подключения. Можно углубиться в теорию, рассчитать эти параметры и составить конфигурацию вручную - но простейший "финт ушами" созданием подставного "разрежённого файла" ("sparse file") за пару секунд даст нам всё нужное.

Выясняем точный размер исходного файла виртуального диска в байтах:

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

Опция "zeroedthick" параметра "--diskformat" указывает создать "sparce"-файл - это происходит буквально мгновенно.
Имя файла для будущего виртуального диска сразу задаём с расширением ".vmdk", следуя правилам "VMware".

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

. 68719476736 . ./example.vm.raw
. 68719476736 . ./example.vm-flat.vmdk
. 499 . ./example.vm.vmdk

Сразу удаляем файл блока данных подставного временного виртуального диска (нам нужен только файл-дискриптор):

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

Корректируем содержимое файла-дискриптора, указывая предпочтительный тип виртуального адаптера (я везде использую "VMware Paravirtual", реализующий наиболее скоростной доступ к ресурсам с минимальной прослойкой абстракции):

Проверяем корректность конфигурации виртуального диска:

. если всё хорошо:

Вуаля, мы сделали это - теперь в панели редактирования параметров виртуальной машины ("VM Hardware") для добавления нового устройства следует выбрать пункт "Existing Hard Disk" и указать на файл-дискриптор "/vmfs/volumes/datastore0/example.vm/example.vm.vmdk" описания такового.

[ уже посетило: 7409 / +4 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Читайте также: