Перенос esxi на kvm

Обновлено: 07.07.2024

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" описания такового.

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

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

Процесс миграции

Из имеющихся возможных вариантов проведения перевода виртуальной машины из среды vSphere в среду Proxmox покажу простейший и как мне кажется наиболее прямолинейный способ.

Во-первых, с помощью веб интерфейса клиента vSphere проводим экспорт виртуальной машины в виде OVF темплейта. Для этого в контекстном меню данной виртуальной машины выбираем Template -> Export OVF Template. Перед выполнением данного действия необходимо убедиться, что сама ВМ находится в выключенном состоянии. В результате выполнения операции экспорта на рабочий компьютер загрузится несколько файлов данной ВМ (ovf, vmdk, nvram, mf).

Во-вторых, загружаем все файлы, полученные в результате предыдущей операции, на сервер Proxmox. Это можно сделать с помощью команды scp в Linux/MacOS или pscp в Windows.

В-третьих, когда все файлы будут загружены, можно начать импорт этих файлов в Proxmox-VE. Пример команды в CLI для импорта ВМ приведен ниже.

Установить в настройках жестких дисках параметр discard=on.
Добавить необходимые сетевые адаптеры.
Выставить параметр QEMU guest agent в Enabled.
Отредактировать название ВМ в случае необходимости.

В-четвертых, пришло время запускать импортированную нами виртуальную машину. Так как в средах vSphere и Proxmox наименование сетевых адаптеров различается, необходимо через VNC консоль гипервизора произвести их переконфигурацию. После этого должна появиться связь с виртуальной машиной из сети. Соответсвенно можно будет заходить на нее удаленно и выполнять дальнешие действия через SSH или RDP. В ряде случаев для нормального функционирования определенных сервисов потребуется перезагрузка гостевой машины.

В-пятых, нам необходимо отключить vmware-tools, и включить qemu agent. Так, например, в случае с использованием Ubuntu Linux в качестве гостевой ОС, нам нужно выполнить две команды в шелле виртуальной машины.

В-шестых, после процедуры импорта, все диски гостевой машины в Proxmox будут занимать полное место на датасторе, вне зависиомсти от использования функионала Thin Provisioning. Если мы используем данную технологию, то необходимо в шелле гостевой машины выполнить следующую команду, чтобы освободить на датасторе неиспользуемое место.

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

Резюме

Алогиртм, расписанный в этой статье, сам по себе не сложный и позволяет в случае необходимости плавно перенести нужное количество гостевых машин из среды VMware в среду Proxmox-VE. Однако, надо понимать, что большая часть задач требует ручного выполнения и отнимает определенное время. В остальном, процесс миграции не должен вызвать затруднений у читателей моего блога.

Многие компании долгое время в качестве гипервизора использовали бесплатную версию ESXi, которая начиналась с 5.0. Это был неплохой и, что главное, незатратный гипервизор, но с более поздними версиями начали проявляться нюансы. Если с ESXi 5.5 – 6.0 еще можно было работать, используя некоторые хитрости, то версия 6.5 стала ужасно неудобной даже для тех, кто пользовался платными решениями. Почему стоит перестать пользоваться ESXi, какие есть альтернативы и что нужно для «переезда» – вы узнаете из нашей статьи .

Почему не ESXi и какие существуют альтернативы

Переход на другой гипервизор – дело нелегкое, к тому же, немало времени занимает адаптация к продукту и его изучение.

В чем проблема версии 6.5, из-за которой возникла необходимость переезда?

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

Разобравшись с причиной переезда, нужно понимать, что именно вы хотите получить. Самыми главными критериями для удобной работы будут: возможность виртуализации в Windows, свежие драйвера и нормальная поддержка сетевых карт, живая миграция, то есть гибридный гипервизор. Этого нет в ESXi, но есть в KVM или LXD. Как переехать с ESXi на KVM/LXD, в чем их преимущество и что выбрать?

Чем удобно использование KVM/LXD

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

QEMU – отдельная программа для визуализации других устройств, она работает довольно медленно, но без проблем;
QEMU – KVM – по сути, модуль ядра для программы QEMU от Linux, он выборочно транслирует не все инструкции, это быстрее и дешевле;
Libvirt – выполняет задачу единственного гипервизора для всех устройств, он работает с чем угодно, правда, это только теория, есть и свои нюансы.

Говоря о LXD – это гипервизор контейнеров, основанный на LXC, аналог libvirt. Он экономит память на ядре, и это его главный плюс. LXD хорош для создания инфраструктуры CI/CD, но для продакшн – слабоват.

То есть, что использовать: KVM или LXD – зависит от ваших задач, но можно создать и симбиоз, что тоже удобно.

90% материалов про постройку сети в KVM или LXD абсолютно бесполезны, поэтому, если вы не до конца разобрались в том, как переехать с ESXi на KVM/LXD, то, возможно, стоит обратиться за консультацией в нашу компанию администрирования серверов.

Основные особенности перехода на KVM/LXD

Если вы уже задались вопросом, как же переехать с ESXi на KVM/LXD, или, возможно, уже переехали, то нужно знать про некоторые особенности работы с этими продуктами.

при установке на свой гипервизор KVM/LXD у вас появится два сетевых моста от каждого устройства, не используйте их! Перейдите на macvtap, особенно если скорость высокая (больше1 Гб/с);
используйте общее хранилище, это удобнее и практичнее, например, это существенно сокращает время миграции;
если монтируете rootfs контейнеры гипервизора, то используйте systemd вместо autofs, так как там нет automount-юнитов.

Теперь вы можете подбирать свои вариации, мигрировать и делать свою работу с гипервизором более комфортной!

Главный претендент на замену коммерческой системы виртуализации 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 ?

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