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
... 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
------------------------
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
...
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
....
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".
Имя файла для будущего виртуального диска сразу задаём с расширением ".vmdk", следуя правилам "VMware".
В результате мы получаем заготовку монолитного блока данных подставного виртуального диска и файл-дискриптор описания его параметров:
[root@node0.vmware] ls -l ./example.vm.*
... 68719476736 ... ./example.vm.raw
... 68719476736 ... ./example.vm-flat.vmdk
... 499 ... ./example.vm.vmdk
... 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"
....
# 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" описания такового.
23 декабря 2021 в 19:36