Linux kvm on esxi

Is it possible to install KVM On A VMWare virtual machine? If so, what are the steps?

I want to understand how to use KVM in CenTOS. At the moment, all I have is a VMWare ESX 5.x server to use. Is there a way to get KVM working on a system that is running on VMWare? Essentially, a nested install? This will not be used for production purposes, only testing/learning.

@Mike B: «install» is misleading most of the time. KVM is just a facility offered by the kernel (accessed through the character device at /dev/kvm ). CentOS should have the kernel module in the kernel package by default (though it could also be compiled-in). What you install is the hypervisor that makes use of KVM (e.g., QEMU).

1 Answer 1

To allow KVM to function inside a VM do the following;

In esxi 5.5 add the following line to your VM to enable nested virtualization;

Steps: go to «edit settings» —->»options»—->»Advanced»—> «General»—>»Configuration Parameters»—->»configuration button, select add row and add the new parameter. hypervisor.cpuid.v0 = «FALSE»

You must log in to answer this question.

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533

Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group.
This site is not affiliated with Linus Torvalds or The Open Group in any way.

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

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

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

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

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

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

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

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

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

О «прореженных» или «схлопываемых» файлах («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») за пару секунд даст нам всё нужное.

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

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

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

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

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

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

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

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

#ddb.adapterType = «lsilogic»
ddb.adapterType = «pvscsi»
.

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

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

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

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

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

Источник