Глава 1. Начало работы с QEMU и KVM

В предыдущем рецепте мы создали некий пустой образ raw. В данном рецепт мы собираемся сделать в нём некий раздел и какую- то файловую систему, подготовив этот образ для полной установки гостевой ОС. При создании таких раздела и файловой системы вам следует рассмотреть тот тип загрузки, который создаст этот виртуальный экземпляр. Если ваше приложение исполняется внутри ВМ с ограниченными операциями ввода/ вывода, вы можете рассмотреть для его файловой системы XFS. В данном рецепте мы собираемся применить EXT4, так как большая часть дистрибутивов Linux боддерживают её сразу после установки.

Для данного рецепта нам понадобятся следующие инструменты:

Большинство дистрибутивов Linux должны уже иметь все эти инструменты установленными, если это не так, ознакомьтесь с документацией своего дистрибутива по поводу того, как их установить.

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

Мы воспользовались преимуществами функциональности, которые предоставляет модуль ядра nbd, предоставляя нам возможность связать некий файл образа raw с блочным устройством при помощи утилиты qemu-nbd. Для получения дополнительной информации об этом модуле ядра исполните следующий код:

root@kvm:~# modinfo nbd
filename: /lib/modules/4.4.0-62-generic/kernel/drivers/block/nbd.ko
license: GPL
description: Network Block Device
srcversion: C67096AF2AE3C738DBE0B7E
depends:
intree: Y
vermagic: 4.4.0-62-generic SMP mod_unload modversions
parm: nbds_max:number of network block devices to initialize (default: 16) (int)
parm: max_part:number of partitions per device (default: 0) (int)
root@kvm:~#
 	   

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

root@kvm:~# file -s /dev/nbd0
/dev/nbd0: x86 boot sector
root@kvm:~#
 	   

После создания двух новых разделов на шаге 3 изменился тип самого файла образа. Давайте опросим его снова:

root@kvm:~# file -s debian.img
debian.img: x86 boot sector
root@kvm:~#
 	   

Теперь, когда у нас имеется файл некого образа, который содержит два раздела и какую- то файловую систему, мы можем продолжить установку своей гостевой ОС в нашем следующем рецепте.

В данном рецепте мы собираемся воспользоваться утилитой debootstrap для установки дистрибутива Debian в том образе raw, который мы подготовили в двух предыдущих рецептах. Сама команда debootstrap применяется для самозагрузки некоторой базовой системы Debian с применением определённого общедоступного зеркала. К концу данного рецепта мы должны иметь некий образ, содержащий полный дистрибутив Linux готовый к исполнению QEMU.

Для выполнения данного рецепта мы будем нуждаться в следующем:

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

root@kvm:~# ls -la /dev/nbd0*
brw-rw---- 1 root disk 43, 0 Feb 10 18:24 /dev/nbd0
brw-rw---- 1 root disk 43, 1 Feb 10 18:24 /dev/nbd0p1
brw-rw---- 1 root disk 43, 2 Feb 10 18:24 /dev/nbd0p2
root@kvm:~#
 	   

Если что- то находится не на своём месте, повторите, пожалуйста, рецепт Подготовка образов для установки ОС при помощи qemu-nbd по поводу того как связать свой образ raw с необходимым блочным устройством /deb/nbd0.

Чтобы установить утилиту debootstrap, если она ещё не присутствует у вас в системе, исполните следующий код:

root@kvm:~# apt install -y debootstrap
...
Setting up debootstrap (1.0.78+nmu1ubuntu1.2) ...
root@kvm:~#
 	   

Для установки некоторого нового дистрибутива Debian в своё устройство raw следуйте набросанным далее шагам:

В предыдущем разделе много чего произошло, поэтому давайте сразу перейдём к командам и обсудим слегка подробнее то, что в точности произошло и почему.

На 1 шаге мы смонтировали свой корневой раздел, который мы создали ранее в своём устройстве /dev/nbd0p2 в /mnt, таким образом, мы можем его применять. Раз монтирование выполнено, на шаге 2 мы устанавливаем весь дистрибутив Debian в этом устройстве применяя в качестве целевой данную точку монтирования.

Чтобы установить необходимый начальный загрузчик GRUB в данном корневом разделе, мы привязываем и монтируем свой каталог /dev из имеющейся файловой системы хоста в файловую систему выстраиваемого образа в /mnt на шаге 4.

Затем на шаге 6 мы применяем инструмент chroot чтобы изменить пространство имён своего каталога с тем, чтобы оно было /mnt, поэтому мы можем выполнять операции так, как будто мы напрямую находимся в этой новой ОС.

На шаге 8 мы монтируем виртуальные файловые системы proc и sysfs внутри данного образа, так как их ожидает начальный загрузчик GRUB.

На шаге 9 мы продолжаем установку исходного кода своего ядра и инструментов GRUB в подготовке к установке самого начального загрузчика в его загрузочный раздел и на шаге 10 мы устанавливаем этот начальный загрузчик.

На шаге 11 были созданы сами файлы настройки GRUB и был обновлён имеющийся образ загрузочного ramdisk.

На шагах 12, 13 и 14 мы изменили установленный пароль root и убедились что мы получаем доступ к певдо- Терминалу, поэтому мы сможем зарегистрироваться в этой ВМ позже, а также изменили текущий уровень исполнения с определённого по умолчанию графического интерфейса на многопользовательский.

Так как имеющийся файл fstab сразу после установки ОС Debian в данном образе является пустым, мы добавили точку монтирования своего корня, иначе наша ВМ не будет иметь возможности запуска. Это было осуществлено на шаге 15.

На шагах 16 и 17 мы выполнили некоторую очистку размонтировав смонтированные нами ранее необходимые файловые системы и вышли из своей среды chroot.

Вернувшись обратно в файловую систему своего хоста на шаге 18, мы установили GRUB в своём устройстве nbd0 определив необходимое положение монтирования данного образа.

На шаге 19 мы обновили имя устройства настройки GRUB на sda2, так как это именно то имя, которое будет возникать внутри данной виртуальной машины после её запуска. Само имя nbd0p2 присутствует только пока мы вынуждены поддерживать связь между своим образом raw и соответствующим сетевым блочным устройством ОС нашего хоста. С точки зрения самой ВМ, именно второй раздел внутри данного созданного нами образа по умолчанию имеет имя sda2.

И, наконец, на шагах 20 и 21 мы выполняем некоторую очистку удаляя имеющуюся точку монтирования и отсоединяя свой образ raw от сетевого блочного устройства nbd0.

В данном рецепте мы собираемся обследовать как изменять размер имеющегося образа raw, размещаемые в нём размеры и саму файловую систему поверх этих разделов.Мы собираемся применять свой образ raw, который мы построили в своих предыдущих рецептах, который содержит разделы подкачки и некоторого корня с отформатированной в нём файловой системой EXT4.

В данном разделе мы собираемся применять следующие инструменты:

Большая часть из этих утилит должна уже быть установлена в Ubuntu, за исключением kpartx. Чтобы установить его, исполните следующее:

root@kvm:~# apt install kpartx
 	   

Приводимые далее шаги демонстрируют как добавить дополнительное пространство в наш образ raw, который мы создали ранее, расширить раздел корня и изменить размер файловой системы. К окончанию данного рецепта первоначальный размер файла образа raw должен измениться с 10 ГБ до 20 ГБ.

Изменение размера для ВМ может быть каким- то образом связано с тем, что мы видели во всех шагах предыдущего раздела. Всё может усложниться если в одном и том же образе имеются несколько разделов Linux, тем более, если мы применяем LVM (Logical Volume Management). Давайте пройдём пошагово по всем выполненным нами ранее командам и более подробно объясним почему мы их выполнили и зачем мы это сделали.

На шаге 1 мы подтвердили значение текущего размера своего образа, которое составляет 10 ГБ.

На шаге 2 мы добавили 10 ГБ в самый конец данного образа и удостоверились, что в этом новом размере образа на шаге 3.

Аннулируем тот образ, который мы построили в предыдущих рецептах и который содержал два раздела, подкачки и корня. Нам нужен способ работать с ними по отдельности. В частности, мы бы желали выделить то дополнительное пространство, которое мы добавили на шаге 2, в свой корневой раздел. Для того чтобы сделать это, нам необходимо выставить его как некое блочное устройство, с которым мы просто сможем манипулировать стандартными утилитами диска и файловой системы. Мы осуществляем это на шаге 5 с применением команды losetup, что в результате делает соответствие между нашим образом и неким новым блочным устройством с именем /dev/loop1. На шаге 6 мы выставляем два индивидуальных раздела как два отображения новых устройств. Причём /dev/mapper/loop1p2 является тем корневым разделом, к которому мы бы хотели добавить в конец всё неиспользуемое дисковое пространство.

Прежде чем мы сможем изменить размер отведённый под раздел в своём петлевом устройстве, нам необходимо проверить целостность его файловой системы и именно это мы выполняем на шаге9. Так как мы применяем файловую систему с журналом, нам необходимо удалить имеющийся журнал, прежде чем мы изменим размер. Мы выполняем это на шаге 10 и убеждаемся что наш атрибут has_journal не отображается после выполнения на шаге 11 команды tune2fs.

Теперь нам необходимо работать напрямую с основным блочным устройством вместо работы с индивидуальными разделами. Мы удаляем установленное соответствие на шагах 12 и 13 и ассоциируем некое новое блочное устройство со своим файлом образа при помощи команды qemu-nbd на шаге 14. Наше новое блочное устройство /dev/nbd0 теперь представляет целиком весь диск данной гостевой ВМ и он напрямую отображает то, что находится внутри данного образа raw. Мы можем применять это блочное устройство в точности так же как другой обычный диск и, что ещё более важно, можем применять инструмент, подобный fdisk для его опроса и манипуляций с расположенными внутри него разделами.

На шаге 15 мы применяем утилиту fdisk для удаления своего корневого раздела и его повторного создания. Это не разрушает никакие данные файловой системы, однако изменяет её метаданные, выделяя то дополнительное пространство, которое мы добавили ранее как часть своего корневого раздела.

Теепрь, когда данное блочное устройство имеет всё выделенной нашему корневому разделу дисковое пространство, нам необходимо расширить саму файловую систему, которая располагается поверх него. Мы делаем это вначале повторно создавая индивидуальное отображение раздела, как мы это делали раньше, чтобы выставить свой корневой раздел напрямую так, чтобы мы могли могли вновь манипулировать им. Мы делаем это на шагах 16 и 17.

На шагах 18 и 19 мы проверяем целостность своей корневой файловой системы, затем мы изменяем её размер до максимального значения доступного дискового пространства в том корневом разделе, в котором она расположена.

Наконец, на шаге 20, мы вновь удаляем имеющееся отображение. Теперь данный образ, а именно корневой раздел внутри данного образа, а также его файловая система EXT4 поверх данного раздела Linux изменены в размере до 20 ГБ.

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

В рецепте Установка пользовательской ОС в образ при помощи debootstrap мы увидели как применять команду debootstrap для установки Debian в построенный нами образ. Большинство вендоров Linux предоставляют уже построенные образы своих дистрибутивов для различных архитектур. Устанавливаемые образы также доступны для ручной установки необходимых гостевых ОС. В данном рецепте мы собираемся продемонстрировать как получить и опробовать образы CentOS и Debian, которые уже были построены. В следующем рецепте мы собираемся показать как запускать QEMU/KVM экземпляры с применением тех же самых образов.

Для данного рецепта нам понадобится QEMU, установленный в ОС нашего хоста. Для получения инструкций о том, как устанавливать QEMU, пожалуйста, воспользуйтесь рецептом Установка и настройка QEMU в этой главе. Нам также потребуется утилита wget для загрузки всех образов с наших восходящих общедоступных репозиториев.

Чтобы получить образы Debian Wheezy для использования c QEMU и KVM выполните следующее:

Чтобы получить образы CentOS выполните следующее:

Имеется множество общедоступных репозиториев во всемирном Интернете, которые предоставляют образы различных типов, причём наиболее распространённым является qcow2 для применения с QEMU/ KVM. В предыдущем разделе мы воспользовались официальным репозиторием CentOS для получения необходимого образа и ещё одним другим, содержащим предварительно построенные образы для Debian.

Оба образа представлены в формате qcow2, что подтверждено на шаге 2.

До сих пор мы только видели как строить, испытывать, манипулировать и загружать образы. Ы следующем рецепте мы собираемся сосредоточиться на том, как на самом деле применять образы для запуска экземпляров QEMU/ KVM/

Для получения дополнительной информации о том, какие предварительно построенные образы доступны для перечисленных дистрибутивов, опросите следующие ссылки:

В данном рецепте мы собираемся продемонстрировать как запускать виртуальные машины при помощи QEMU. QEMU предоставляет исполняемые файлы, которые могут эмулировать различные архитектуры WGE с применением либо пользовательских, либо предварительно построенных образов для необходимых гостевых ОС.

Если вы выполнили рецепт рецептом Установка и настройка QEMU, вы уже должны иметь хост который содержит следующие исполняемые файлы:

root@kvm:~# ls -la /usr/bin/qemu-system-*
-rwxr-xr-x 1 root root 8868848 Jan 25 12:49 /usr/bin/qemu-system-aarch64
-rwxr-xr-x 1 root root 7020544 Jan 25 12:49 /usr/bin/qemu-system-alpha
-rwxr-xr-x 1 root root 8700784 Jan 25 12:49 /usr/bin/qemu-system-arm
-rwxr-xr-x 1 root root 3671488 Jan 25 12:49 /usr/bin/qemu-system-cris
-rwxr-xr-x 1 root root 8363680 Jan 25 12:49 /usr/bin/qemu-system-i386
-rwxr-xr-x 1 root root 3636640 Jan 25 12:49 /usr/bin/qemu-system-lm32
-rwxr-xr-x 1 root root 6982528 Jan 25 12:49 /usr/bin/qemu-system-m68k
-rwxr-xr-x 1 root root 3652224 Jan 25 12:49 /usr/bin/qemu-system-microblaze
-rwxr-xr-x 1 root root 3652224 Jan 25 12:49 /usr/bin/qemu-system-microblazeel
-rwxr-xr-x 1 root root 8132992 Jan 25 12:49 /usr/bin/qemu-system-mips
-rwxr-xr-x 1 root root 8356672 Jan 25 12:49 /usr/bin/qemu-system-mips64
-rwxr-xr-x 1 root root 8374336 Jan 25 12:49 /usr/bin/qemu-system-mips64el
-rwxr-xr-x 1 root root 8128896 Jan 25 12:49 /usr/bin/qemu-system-mipsel
-rwxr-xr-x 1 root root 3578592 Jan 25 12:49 /usr/bin/qemu-system-moxie
-rwxr-xr-x 1 root root 3570848 Jan 25 12:49 /usr/bin/qemu-system-or32
-rwxr-xr-x 1 root root 8701760 Jan 25 12:49 /usr/bin/qemu-system-ppc
-rwxr-xr-x 1 root root 9048000 Jan 25 12:49 /usr/bin/qemu-system-ppc64
lrwxrwxrwx 1 root root 17 Jan 25 12:49 /usr/bin/qemu-system-ppc64le -> qemu-system-ppc64
-rwxr-xr-x 1 root root 8463680 Jan 25 12:49 /usr/bin/qemu-system-ppcemb
-rwxr-xr-x 1 root root 6894528 Jan 25 12:49 /usr/bin/qemu-system-sh4
-rwxr-xr-x 1 root root 6898624 Jan 25 12:49 /usr/bin/qemu-system-sh4eb
-rwxr-xr-x 1 root root 4032000 Jan 25 12:49 /usr/bin/qemu-system-sparc
-rwxr-xr-x 1 root root 7201696 Jan 25 12:49 /usr/bin/qemu-system-sparc64
-rwxr-xr-x 1 root root 3704704 Jan 25 12:49 /usr/bin/qemu-system-tricore
-rwxr-xr-x 1 root root 3554912 Jan 25 12:49 /usr/bin/qemu-system-unicore32
-rwxr-xr-x 1 root root 8418656 Jan 25 12:49 /usr/bin/qemu-system-x86_64
-rwxr-xr-x 1 root root 3653024 Jan 25 12:49 /usr/bin/qemu-system-xtensa
-rwxr-xr-x 1 root root 3642752 Jan 25 12:49 /usr/bin/qemu-system-xtensaeb
root@kvm:~#
 	   

Каждая команда способна запустить экземпляр с эмуляцией QEMU для определённой архитектуры ЦПУ. Для данного рецепта мы собираемся воспользоваться утилитой qemu-system-x86_64 .

Для завершения данного рецепта вам необходимо следующее:

Давайте взглянем на то какие архитектуры ЦПУ поддерживает QEMU в данной системе хоста:

root@kvm:~# qemu-system-x86_64 --cpu help
x86 qemu64 QEMU Virtual CPU version 2.5+
x86 phenom AMD Phenom(tm) 9550 Quad-Core Processor
x86 core2duo Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
x86 kvm64 Common KVM processor
x86 qemu32 QEMU Virtual CPU version 2.5+
x86 kvm32 Common 32-bit KVM processor
x86 coreduo Genuine Intel(R) CPU T2600 @ 2.16GHz
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon QEMU Virtual CPU version 2.5+
x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz
x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7)
x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C)
x86 SandyBridge Intel Xeon E312xx (Sandy Bridge)
x86 IvyBridge Intel Xeon E3-12xx v2 (Ivy Bridge)
x86 Haswell-noTSX Intel Core Processor (Haswell, no TSX)
x86 Haswell Intel Core Processor (Haswell)
x86 Broadwell-noTSX Intel Core Processor (Broadwell, no TSX)
x86 Broadwell Intel Core Processor (Broadwell)
x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron)
x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron)
x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron)
x86 Opteron_G4 AMD Opteron 62xx class CPU
x86 Opteron_G5 AMD Opteron 63xx class CPU
x86 host KVM processor with all supported host features (only available in KVM mode)

Recognized CPUID flags:
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 pn clflush ds acpi mmx fxsr sse sse2 ss ht tm ia64 pbe
pni|sse3 pclmulqdq|pclmuldq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cid fma cx16 xtpr pdcm pcid dca sse4.1|sse4_1 sse4.2|sse4_2 x2apic movbe popcnt tsc-deadline aes xsave osxsave avx f16c rdrand hypervisor
fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f rdseed adx smap pcommit clflushopt clwb avx512pf avx512er avx512cd
syscall nx|xd mmxext fxsr_opt|ffxsr pdpe1gb rdtscp lm|i64 3dnowext 3dnow
lahf_lm cmp_legacy svm extapic cr8legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb
invtsc
xstore xstore-en xcrypt xcrypt-en ace2 ace2-en phe phe-en pmm pmm-en
kvmclock kvm_nopiodelay kvm_mmu kvmclock kvm_asyncpf kvm_steal_time kvm_pv_eoi kvm_pv_unhalt kvmclock-stable-bit
npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pause_filter pfthreshold
xsaveopt xsavec xgetbv1 xsaves
arat
root@kvm:~#
 	   

Из предыдущего вывода мы можем увидеть полный список тех ЦПУ, которые могут передаваться в параметрах через флаг -cpu для эмуляции этого типа ЦПУ внутри нашей виртуальной машины.

Чтобы запустить некую новую виртуальную машину при помощи утилиты qemu-system исполните такие шаги:

Как запустить некую виртуальную машину при помощи QEMU/ KVM зависит в основном от имеющегося типа образа и того, как этот раздел структурирован внутри данного образа.

Мы воспользовались двумя разными типами образа с различными схемами разделов чтобы продемонстрировать это понятие.

На шаге 1 мы применили команду qemu-system-x86_64 для эмуляции некоторой архитектуры ЦПУ x86_64, в частности, мы передали флаг -cpu Nehalem, эмулирующий модель определённую модель ЦПУ Nehalem. Флагом -vnc мы передали в качестве параметра конкретный адрес IP своего сервера. Это запустит какой- то сервер VNC в данной ВМ с тем, чтобы мы могли позже воспользоваться неким клиентом VNC для соединения с данным экземпляром QEMU. Мы определили значение объёма памяти, которая должна быть выделена данному экземпляру, в данном случае, 1 ГБ, при помощи флага -m. Мы проинструктировали QEMU, что мы собираемся использовать некий образ raw посредством опции format=raw, а также название и расположение реального образа через параметр file=debian.img.

Напомним, что этот образ содержит два раздела, причём второй раздел содержит корневую файловую систему, в которой содержится начальный загрузчик. Очень важно не забывать это, так как нам необходимо определить какой индекс раздела следует загужать нашей гостевой ОС. Мы делаем это с помощью флага index=2. Наконец, мы передаём параметр -daemonize для установки процесса QEMU в фоновый режим.

На шаге 4 мы запускаем другой экземпляр QEMU, в этот раз применив образ CentOS qcow2, который мы загрузили ранее. Мы не должны определять из какого раздела нам нужно загружаться в нём на этот раз, так как большинство предварительно построенных образов используют первый раздел, или имеют всего один раздел. Мы также применяем флаг -hda вместо параметра -drive, просто чтобы продемонстрировать что оба варианта можно применять с одним и тем же результатом. Этот флаг -hda сообщает QEMU самый первый диск для данного экземпляра, который следует загрузить с того имени файла, которое следует за ним.

В данном рецепте мы собираемся запустить некуб виртуальную машину QEMU с ускорением KVM. KVM (Kernel-based Virtual Machine) является полной технологией виртуализации для архитектур ЦПУ, которые поддерживают расширения виртуализации. Для процессоров на основе Intel это именно Intel VT, а для ЦПУ AMD это аппаратное расширение AMD-V. Главными частями KVM являются два загружаемых модуля ядра с именами, первый kvm.ko, который предоставляет всю основную функциональность виртуализации, а также второй модуль ядра, который определяется процессором, а именно kvm-intel.ko и kvm-amd.ko для двух основных производителей ЦПУ.

QEMU яляется определённым компонентом пользовательского пространства для создания виртуальных машин, тогда как KVM располагается в пространстве ядра. Если вы выполняли компиляцию в рецепте Выполнение ВМ при помощи qemu-system-*, вы должны были заметить, что основная разница между исполнением виртуальной машины KVM и исполнением экземпляра QEMU бкз ускорения состоит всего в одной опции командной строки.

Чтобы запустить некий экземпляр KVM, вам потребуется следующее:

Чтобы проверить поддерживает ли ваш ЦПУ виртуализацию, исполните такой код:

root@kvm:~# cat /proc/cpuinfo | egrep "vmx|svm" | uniq
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm arat pln pts
root@kvm:~#
 	   

Наличие соответствующего флага vmx (для Intel) или svm (для AMD) является индикатором того, что ваш ЦПУ поддерживает все необходимые расширения виртуализации.

Чтобы вручную загрузить необходимый модуль KVM и гарантировать что он был загружен, выполните следующий код:

root@kvm:~# modprobe kvm
root@kvm:~# lsmod | grep kvm
kvm 455843 0
root@kvm:~#
 	   

Для запуска некоторого экземпляра KVM, проверки того что он запущен и в конце концов его останова исполните следующее:

Чтобы запустить виртуальную машину QEMU/KVM, всё что нам требуется сделать в отличии от того, что мы выполняли в нашем рецепте Установка и настройка QEMU, это передача флага -enable-kvm в команде qemu-system-x86_64.

На шаге 1 мы определили некоторое имя для своей ВМ с помощью флага -name, предоставили IP адрес физического хоста в флаг -vnc , включили доступ VNC для данного виртуального экземпляра, выделили 1 ГБ памяти в флаге -m, определили тот раздел, где размещён начальный загрузчик с помощью параметра index=2, задали формат образа и, наконец, мы разрешили аппаратное ускорение KVM воспользовавшись параметром -enable-kvm и демонизировали этот процесс {Прим. пер.: перевели в фоновый режим} флагом -daemonize.

На шаге 2 мы убедились, что этот экземпляр исполняется, а на 3 шаге прекратили его.

В качестве альтернативы исполнению напрямую команд qemu-system-*, в системе Ubuntu имеется пакет qemu-kvm, который предоставляет все исполняемые файлы /usr/bin/kvm. Эти файлы обёрнуты в команду qemu-system-x86_64, а она передаёт им параметр -enable-kvm автоматически.

Чтобы установить этот пакет и вместо всего воспользоваться командой kvm , исполните следующее:

root@kvm:~# apt install qemu-kvm
...
root@kvm:~# kvm -name debian -vnc 146.20.141.254:0 -cpu Nehalem -m 1024 -drive format=raw,index=2,file=debian.img -daemonize
root@kvm:~# pgrep -lfa qemu
25343 qemu-system-x86_64 -enable-kvm -name debian -vnc 146.20.141.254:0 -cpu Nehalem -m 1024 -drive format=raw,index=2,file=debian.img -daemonize
root@kvm:~#
 	   

Вы должны были отметить, что запуск и останов экземпляров QEMU/KVM является неким выполняемым вручную процессом, в особенности необходимость уничтожения запущенного экземпляра процесса для его останова. В Главе 2, Применение libvirt для управления KVM мы пройдёмся по набору рецептов, которые сделают управление общим жизненным циклом виртуальных машин KVM намного более простым за счёт инчтрументов пользовательского пространства , которые предлагает пакет libvirt.

В данном рецепте мы собираемся подключиться к некоторому исполняемому экземпляру KVM с использованием клиента VNC. После соединения мы намереваемся зарегистрироваться и проверить тип ЦПУ и доступную память для этого экземпляра. Мы уже видели как запускать экземпляры QEMU/KVM с поддержкой VNC в предыдущих рецептах, но мы собираемся сделать это снова, на случай если вы читаете книгу от корки до корки.

VNC (Virtual Network Computing) применяет пртокол RFB (Remote Frame Buffer) для удалённого управления другой системой. Он передаёт все экраны с такого удалённого компьютера обратно своему клиенту, делая доступным полное управление клавиатурой и мышью.

Имеется множество различных клиентов VNC и реализаций сервера, однако для данного рецепта мы собираемся применять свободно распространяемую версию, именуемую цыплёнком VNC для macOS. Вы можете загрузить этого клиента с https://sourceforge.net/projects/cotvnc/.

Чтобы исполнить данный рецепт, вам понадобится следующее:

На шаге 1 мы запускаем новй экземпляр QEMU с ускорением KVM и включаем сервер VNC в нём с определёнными IP адресом и потром дисплея. Мы определили объём доступной памяти и название данной модели ЦПУ.

На шаге 4 мы регистрируемся в этом экземпляре применяя пользователя root и тот пароль, который мы создали при построении данного образа, затем получаем необходимую информацию ЦПУ исполнив команду lscpu. От метим, что название модели ЦПУ соответствует той, что мы определяем во флаге -cpu при запуске данной виртуальной машины. Далее мы проверяем выделение памяти при помощи команды free, которая также соответствует ранее определённому параметром -m значению.