UMGUM.COM 

Qemu-KVM HDD to "VMware ESXi" (CLI) ( Адаптация образа виртуального диска системы виртуализации Qemu-KVM для эксплуатации в "VMware ESXi". )

1 октября 2018

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" для размещения там конфигурационных файлов, что в общем неудобно.

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

[root@node0.vmware] ls -lh /vmfs/volumes/datastore0/example.vm

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

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

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

root@node0.kvm:# virsh list --all

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-формат:

root@node0.kvm:# qemu-img convert -f qcow2 ./example.vm.qcow2 -O raw ./example.vm.raw

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

root@node0.kvm:# qemu-img info ./example.vm.qcow2

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

root@node0.kvm:# qemu-img info ./example.vm.raw

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

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

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

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

root@node0.kvm:# ls -lh ./example.vm.raw

... 64G ... ./example.vm.raw

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

root@node0.kvm:# du -sh ./example.vm.raw

4.0G ./example.vm.raw

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

root@node0.kvm:# du -sh --apparent-size ./example.vm.raw

64G ./example.vm.raw

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

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

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

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

root@node0.kvm:# dd < /dev/kvm-storage-vg/example.vm bs=256M | ssh root@node0.vmware "dd > /vmfs/volumes/datastore0/example.vm/example.vm.raw bs=256M"

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

root@node0.kvm:# scp ./example.vm.raw root@node0.vmware:/vmfs/volumes/datastore0/example.vm/

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

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

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

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

[root@node0.vmware] ls -l ./example.vm.raw

... 68719476736 ... ./example.vm.raw

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

[root@node0.vmware] vmkfstools --createvirtualdisk 68719476736 --diskformat zeroedthick ./example.vm.vmdk

Где:

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

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

[root@node0.vmware] ls -l ./example.vm.*

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

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

[root@node0.vmware] rm ./example.vm-flat.vmdk

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

[root@node0.vmware] mv ./example.vm.raw ./example.vm-flat.vmdk

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

[root@node0.vmware] vi ./example.vm.vmdk

....
# The Disk Data Base
#DDB

#ddb.adapterType = "lsilogic"
ddb.adapterType = "pvscsi"
....

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

[root@node0.vmware] vmkfstools --chainConsistent ./example.vm.vmdk

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

Disk chain is consistent.

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


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )