Opublikowano: 08/08/2020 Zaktualizowano: 09/12/2023 Kategorie: Linux

Wirtualizacja QEMU/KVM (libvirt) na Debian Linux

Spis treści

Prawdopodobnie dla większości użytkowników linux'a, wirtualizacja kojarzy się w zasadzie z jednym oprogramowaniem, tj. VirtualBox. Niby strona VBox'a podaje, że jest on na licencji GPL-2 ale w Debianie nie ma go w głównym repozytorium (jest on obecny w sekcji contrib ). Problem z VirtualBox'em jest taki, że wymaga on kompilatora Open Watcom, który już wolnym oprogramowaniem nie jest. VBox też nie jest jedynym oprogramowaniem, które na linux można wykorzystać w roli hiperwizora do obsługi maszyn wirtualnych. Jest o wiele lepsze rozwiązanie, mianowicie QEMU, które jest w stanie zrobić użytek z maszyny wirtualnej kernela (Kernel Virtual Machine, KVM) i realizować dokładnie to samo zadanie, które zwykł ogarniać VirtualBox. Wirtualizacja na bazie QEMU/KVM jest w pełni OpenSource, co ucieszy pewnie fanów wolnego i otwartego oprogramowania, choć zarządzanie maszynami wirtualnymi odbywa się za sprawą konsoli. Oczywiście, osoby które korzystają z VirtualBox'a zdają sobie sprawę, że to narzędzie oferuje graficzny menadżer maszyn wirtualnych (Virtual Machine Manager, VMM), który usprawnia i znacznie ułatwia zarządzanie wirtualnymi maszynami. Jeśli GUI jest dla nas ważnym elementem środowiska pracy i nie uśmiecha nam się konfigurować maszyn wirtualnych przy pomocy terminala, to jest i dobra wiadomość dla takich osób, bo istnieje virt-manager , który jest dość rozbudowanym menadżerem maszyn wirtualnych pozwalającym na ich tworzenie, konfigurowanie i zarządzanie nimi przy wykorzystaniu graficznego interfejsu użytkownika. W tym artykule postaramy się skonfigurować naszego Debiana w taki sposób, by przygotować go do pracy z maszynami wirtualnymi posługując się qemu/libvirt/virt-manager .

Terminy związane z wirtualizacją

Szukając informacji na necie dotyczących QEMU/KVM nie sposób nie natknąć się na szereg dziwnych i trudnych słów związanych z różnymi technikami wirtualizacji. Poniżej zostały zebrane i opisane te częściej wykorzystywane sformułowania, a to z tego względu, że w sporej części te terminy są mylone, nierozróżniane lub stosowane zamiennie i ciężko jest się czasem połapać o czym ktoś pisze czy mówi.

Różnica między emulacją a wirtualizacją

Terminy emulacja i wirtualizacja są podobne, choć mają w stosunku do siebie kilka różnic. Emulacja polega na tym, że jeden system imituje inny system. Dla przykładu, jeśli jakiś kawałek oprogramowania działa w systemie ARM (np. Android) i nie działa jednocześnie na innym systemie, np. naszym domowym PC (x86), to możemy sprawić, że nasz domowy PC będzie emulował działanie systemu ARM, tak by ten kawałek oprogramowania uruchomił się również na systemie x86. Gdybyśmy w tej samej sytuacji chcieli skorzystać z wirtualizacji (zamiast emulacji), to musielibyśmy nasz system x86 podzielić na dwa wirtualne systemy: x86 i ARM. Każdy z tych wirtualnych systemów byłby niezależnym kontenerem oprogramowania mającym swój własny dostęp do programowych zasobów (CPU, RAM, dysk i sieć). Każdy z tych systemów można by też niezależnie uruchomić ponownie. Te wirtualne maszyny zachowywałyby się dokładnie tam samo jak prawdziwy sprzęt fizyczny, przez co aplikacje/systemy operacyjne uruchomione w ich obrębie nie byłby w stanie zauważyć jakiejkolwiek różnicy.

W przypadku emulacji, to oprogramowanie zastępuje sprzęt tworząc odpowiednie środowisko sprzętowe. Niestety taki zabieg sprawia, że spora część cykli procesora jest oddelegowana do obsługi procesu emulacji, przez co tylko część cykli procesora może być przeznaczona na przeprowadzanie faktycznych obliczeń. W ten sposób spada dość znacznie wydajność emulowanych aplikacji/OS. Emulacja jest bardzo przydatna przy projektowaniu oprogramowania na wiele systemów operacyjnych -- można to zrobić w obrębie jednej maszyny fizycznej, co znacznie ułatwia testowanie, ogranicza koszty i przyśpiesza cały proces.

W przypadku wirtualizacji, szybka maszyna fizyczna z dużą ilością pamięci RAM oraz wystarczającą ilością przestrzeni dyskowej może być podzielona na wiele mniejszych maszyn wirtualnych, z której każda ma własne zasoby sprzętowe. Każda z tych maszyn może zostać wdrożona jako osobny serwer hostujący jakieś usługi, np. serwer WWW czy email. W taki sposób te zasoby obliczeniowe, które szły na obsługę emulacji, są teraz dostępne i można je w pełni wykorzystać, co może pomóc w znacznym cięciu kosztów.

W emulowanych środowiskach istnieje potrzeba zastosowania programowego połączenia zapewniającego interakcję z fizycznym sprzętem. W przypadku wirtualizacji, ten dostęp do sprzętu odbywa się bezpośrednio. Mimo, że wirtualizacja jest na ogół szybszą opcją, to jest ona ograniczona przez oprogramowanie będące w stanie działać na podległym sprzęcie fizycznym.

Typy hiperwizorów

Rozróżnia się trzy typy hiperwizorów. Pierwszym z nich jest natywny hiperwizor, który jest aplikacją uruchomioną bezpośrednio na sprzęcie (bare metal), przykładowo Xen, VMWare ESX. Ten typ wymaga dedykowanych sterowników sprzętu dla hiperwizora. Drugim typem jest hostowany hiperwizor, który to jest uruchamiany w obrębie jakiegoś systemu operacyjnego, przykładowo VirtualBox, QEMU, KVM. Tutaj zarządzanie sterownikami leży po stronie systemu operacyjnego hosta. Trzecim typem hiperwizora jest sam system operacyjny, na którym mogą być uruchamiane różnego rodzaju kontenery, przykładowo chroot, LXC czy Docker.

Techniki wirtualizacji

W przypadku procesorów możemy mieć do czynienia z kilkoma technikami wirtualizacji, tj. z pełną wirtualizacją, parawirtualizacją oraz wirtualizacją wspomaganą sprzętowo. Poniżej jest prosta grafika (źródło) obrazująca różnice pomiędzy tymi technikami wirtualizacji procesora:

virtualization-techniques-linux-qemu-kvm-processor

Kolejno od lewej: brak wirtualizacji, pełna wirtualizacja, parawirtualizacja i jako ostatnia wirtualizacja wspomagana sprzętowo.

Jeśli zaś chodzi o terminy wykorzystane w tej powyższej grafice, to:

OS -- system operacyjny (kernel) hosta.
Guest OS -- system operacyjny gościa (maszyny wirtualnej).
User Apps -- aplikacje przestrzeni/poziomu użytkownika.
VMM -- Monitor/Menadżer Maszyn Wirtualnych (Virtual Machine Monitor/Manager), choć w powszechnym użyciu stosuje się częściej termin hiperwizor (Hypervisor).
Virtualization Layer -- warstwa wirtualizacji hiperwizora.
Ring 0-3 -- pierścień ochrony. Im wyższy numer, tym aplikacja działająca w jego obrębie ma mniejsze uprawnienia. W Ring 3 działają procesy przestrzeni użytkownika, w Ring 2 i Ring 1 działają sterowniki urządzeń, w Ring 0 działa system operacyjny (kernel).
Direct execution -- bezpośrednie wykonywanie zapytań aplikacji przestrzeni/poziomu użytkownika.
Binary translation -- binarna translacja zapytań systemu operacyjnego.
Hipercall -- wywołanie hiperwizora umożliwiające bezpośrednią komunikację systemu operacyjnego gościa z warstwą wirtualizacji hiperwizora. Hypercall dla hiperwizora jest w zasadzie tym samym co syscall (wywołanie systemowe) dla kernela.
Non-root Mode Privilege Levels -- tryby nieadministracyjne poziomów uprzywilejowania (Ring 0-3).
Root Mode Privilege Levels -- tryb administracyjny poziomów uprzywilejowania (Ring -1).

Pełna wirtualizacja

Pełną wirtualizację (full virtualization) można osiągnąć przez zastosowanie binarnej translacji zapytań systemu operacyjnego (binary translation of OS requests) w połączeniu z bezpośrednim wykonywaniem zapytań aplikacji przestrzeni/poziomu użytkownika (direct execution of user requests). W takim przypadku system operacyjny gościa jest w pełni oddzielony od sprzętu, na którym działa, przez warstwę wirtualizacji -- ma własny wirtualny BIOS, wirtualne urządzenia i zwirtualizowane zarządzanie pamięcią. System gościa nie jest świadomy faktu bycia wirtualizowanym i nie wymaga żadnych modyfikacji do poprawnego działania. Pełna wirtualizacja jest w zasadzie jedyną opcją, która nie wymaga pomocy od sprzętu lub systemu operacyjnego przy wirtualizacji instrukcji wrażliwych (zmieniających konfigurację zasobów OS) i uprzywilejowanych (powodujących przerwania i wywołania systemowe). Hiperwizor tłumaczy wszystkie instrukcje systemu operacyjnego (kernela) w locie i buforuje wyniki w cache dla przyszłego wykorzystania, podczas gdy instrukcje przestrzeni użytkownika nie są w żaden sposób zmieniane i są wykonywane z prędkością natywną. Pełna wirtualizacja oferuje najlepszą izolację i bezpieczeństwo maszyn wirtualnych. Dodatkowo, ten sam system gościa może bez problemu działać zarówno na maszynie wirtualnej jak i bezpośrednio na natywnym sprzęcie hosta.

Parawirtualizacja

Z parawirtualizacją (paravirtualization, OS Assisted Virtualization) mamy do czynienia wtedy, gdy system operacyjny gościa (maszyny wirtualnej) komunikuje się z hiperwizorem w celu poprawy wydajności. Parawirtualizacja wymaga modyfikacji jądra systemu operacyjnego w celu zastąpienia niemożliwych do zwirtualizowania instrukcji wywołaniami hiperwizora (hypercall). Hiperwizor zapewnia także interfejsy hiperwołań (hypercalls) dla innych krytycznych operacji jądra operacyjnego, takich jak zarządzanie pamięcią, obsługa przerwań i utrzymywanie czasu. W przypadku parawirtualizacji mamy mniejszy narzut (overhead) związany z samym zadaniem wirtualizacji niż przy pełnej wirtualizacji, choć zysk wydajnościowy w porównaniu do niej zależy w dużej mierze od obciążenia, któremu podda się system gościa. Przykładem parawirtualizacji jest projekt Xen, który wirtualizuje procesor i pamięć wykorzystując do tego zmodyfikowane jądro linux'a oraz wirtualizuje I/O przy użyciu niestandardowych sterowników urządzeń systemu operacyjnego gościa.

Wirtualizacja wspomagana sprzętowo

Wirtualizacja wspomagana sprzętowo umożliwia pełne odizolowanie maszyn wirtualnych i osiągana jest przez implementowanie dodatkowych rozszerzeń bezpośrednio w procesorach. Procesory Intel dysponują technologią VT-x, a procesory AMD mają AMD-V. Te technologie dodają nowe uprzywilejowane instrukcje wirtualizacji dla hiperwizora, które pozwalają mu działać w nowym trybie administracyjnym (root mode) poniżej Ring 0 (zwykle stosowany termin Ring -1 ). W taki sposób, system operacyjny gościa jest w stanie wykonywać natywnie operacje przeznaczone dla Ring 0 (dostęp do sprzętu) bez wpływania w żaden sposób na inne systemy gościa czy też system operacyjny hosta. W tej technice wirtualizacji wrażliwe i uprzywilejowane instrukcje są automatycznie przechwytywane przez hiperwizor, przez co nie ma potrzeby stosowania już binarnej translacji czy też parawirtualizacji.

Wirtualizacja pamięci RAM

Procesor nie jest jedynym elementem, który trzeba poddać wirtualizacji. Podobnie trzeba postąpić w przypadku pamięci RAM, wliczając w to dzielenie fizycznej pamięci operacyjnej oraz dynamiczny jej przydział maszynom wirtualnym. Wirtualizacja pamięci maszyny wirtualnej jest bardzo podobna do obsługi pamięci wirtualnej zapewnianej przez nowsze systemy operacyjne. Aplikacje widzą ciągłą przestrzeń adresową, która niekoniecznie jest powiązana z podstawową pamięcią fizyczną w systemie. System operacyjny zachowuje odwzorowania numerów stron wirtualnych na numery stron fizycznych przechowywanych w tablicach stron. Wszystkie nowoczesne procesory x86 zawierają jednostkę zarządzania pamięcią (Memory Management Unit, MMU) i bufor TLB (Translation Lookaside Buffer) w celu optymalizacji wydajności pamięci wirtualnej. Aby uruchomić wiele maszyn wirtualnych na jednym systemie hosta, wymagany jest dodatkowy poziom wirtualizacji pamięci. Innymi słowy, by być w stanie obsłużyć system gościa należy zwirtualizować MMU. System gościa nadal kontroluje mapowanie adresów wirtualnych do pamięci gościa, ale system gościa nie może mieć bezpośredniego dostępu do rzeczywistej pamięci operacyjnej maszyny hosta. Hiperwizor jest odpowiedzialny za mapowanie pamięci fizycznej gościa na rzeczywistą pamięć maszyny hosta i wykorzystuje cieniste tablice stron (shadow page tables) by to mapowanie przyśpieszyć. Hiperwizor wykorzystuje sprzętowy TLB do mapowania pamięci wirtualnej bezpośrednio do pamięci maszyny hosta aby uniknąć dwóch poziomów translacji przy każdym dostępie. Gdy system gościa zmienia mapowanie pamięci, hiperwizor aktualizuje cieniste tablice stron aby umożliwić bezpośrednie wyszukiwanie.

virtualization-techniques-linux-qemu-kvm-memory

Wirtualizacja urządzeń oraz operacji I/O

Poza wirtualizacją procesora i pamięci wymagana jest także wirtualizacja urządzeń oraz operacji wejścia/wyjścia (I/O). Ten proces obejmuje zarządzanie zapytaniami I/O między urządzeniami wirtualnymi a współdzielonym sprzętem fizycznym. Programowa wirtualizacja I/O daje wiele możliwości i znacznie upraszcza zarządzanie urządzeniami. Dla przykładu, wirtualne interfejsy sieciowe i przełączniki tworzą wirtualne sieci pomiędzy maszynami wirtualnymi, przez co nie korzystają z fizycznych interfejsów sieciowych i nie obciążają w żaden sposób sieci hosta. Kluczem do efektywnej wirtualizacji I/O jest zachowanie zalet wirtualizacji przy jednoczesnym ograniczeniu dodatkowego wykorzystania procesora do minimum. Hiperwizor wirtualizuje sprzęt fizyczny i przedstawia każdej maszynie wirtualnej ustandaryzowany zestaw urządzeń wirtualnych. Te urządzenia wirtualne efektywnie emulują dobrze znany sprzęt i tłumaczą zapytania maszyny wirtualnej na zapytania do urządzeń hosta.

Co to jest KVM, QEMU i libvirt

KVM (Kernel-based Virtual Machine), to otwartoźródłowa technologia wirtualizacji wbudowana bezpośrednio w kernel linux'a, pozwalająca maszynie hosta na uruchomienie wielu izolowanych środowisk wirtualnych szerzej znanych jako maszyny wirtualne lub systemy gościa. KVM w zasadzie zapewnia linux'owi możliwości hiperwizora, co oznacza, że szereg jego komponentów, takich jak zarządzanie pamięcią, planista/dyspozytor (scheduler), stos sieciowy, itp. są dostarczane jako część kernela linux. Maszyny wirtualne są w ten sposób zwykłymi procesami w systemie hosta mającymi dedykowany wirtualny sprzęt, taki jak np. adaptery sieciowe. KVM jest dostarczany w formie modułu kvm.ko będącym rdzeniem infrastruktury wirtualizacji oraz modułów specyficznych dla rodzaju procesora, tj. kvm-intel.ko dla procesorów Intel, oraz kvm-amd.ko dla procesorów AMD.

QEMU to Quick Emulator jest to w zasadzie emulator maszyn i zarazem wirtualizator (hostowany hiperwizor). Gdy QEMU jest wykorzystywany w roli emulatora, to jest on w stanie uruchomić pojedyncze aplikacje (albo też i całe systemy operacyjne) przeznaczone na konkretne maszyny (np. ARM), na innych maszynach, np. na nasz domowy PC. Jeśli zaś QEMU jest wykorzystywany w roli hiperwizora, to jest on w stanie wykonywać kod gościa (maszyny wirtualnej) bezpośrednio na procesorze hosta, co przyśpiesza znacząco wydajność maszyny wirtualnej, która mocno zbliżona jest do tej natywnej, tak jakby system maszyny wirtualnej działał bezpośrednio na maszynie hosta. QEMU w roli hiperwizora jest w stanie robić użytek z technologi wirtualizacji oferowanej przez kernel linux'a i w ten sposób kod binarny maszyny wirtualnej może być wykonywany bez emulacji CPU i problemów z nią związanymi (słaba wydajność). Maszyna wirtualna może zostać uruchomiona przy pomocy wiersza poleceń qemu, gdzie można też określić wszystkie niezbędne opcje konfiguracyjne dla QEMU.

Libvirt z kolei jest interfejsem, który tłumaczy konfigurację zapisaną w plikach XML na wywołania qemu . Libvirt dostarcza także demona, który jest w stanie skonfigurować procesy potomne qemu w taki sposób, by nie potrzebowały one uprawnień administratora root. By uruchomić maszynę wirtualną, libvirt jest wykorzystywany do zestawienia procesu qemu dla każdej takiej maszyny osobno.

Czy mój komputer/procesor/linux wspiera wirtualizację

Zanim przejdziemy do głównej części tego artykułu jaką jest konfiguracja maszyn wirtualnych pod linux, trzeba sobie zadać pytanie czy nasz komputer (a w zasadzie jego procesor) posiada wsparcie dla sprzętowej wirtualizacji. Ten krok sprowadza się w zasadzie do przejrzenia pliku /proc/cpuinfo w poszukiwaniu określonej flagi. Jeśli mamy procesor Intel, to szukamy za vmx (Virtual Machine Extensions), a jeśli AMD, to za svm (Secure Virtual Machine). Poniżej są informacje na temat procesora Intel i5-3320M (a konkretnie jednego z jego rdzeni), który figuruje w moim ThinkPad T430:

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
stepping        : 9
microcode       : 0x21
cpu MHz         : 1375.278
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
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 rdtscp lm constant_
                  tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf
                  pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid
                  sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_
                  lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept
                  vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d
vmx flags       : vnmi preemption_timer invvpid ept_x_only flexpriority tsc_offset vtpr mtf
                  vapic ept vpid unrestricted_guest
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_
                  multihit srbds
bogomips        : 5188.31
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Jak widać, flaga vmx jest obecna, zatem ten procesor ma wsparcie dla sprzętowej wirtualizacji.

Można także posłużyć się narzędziem lscpu :

# lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   36 bits physical, 48 bits virtual
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              2
Core(s) per socket:              2
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           58
Model name:                      Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
Stepping:                        9
CPU MHz:                         2416.594
CPU max MHz:                     3300.0000
CPU min MHz:                     1200.0000
BogoMIPS:                        5188.07
Virtualization:                  VT-x
L1d cache:                       64 KiB
L1i cache:                       64 KiB
L2 cache:                        512 KiB
L3 cache:                        3 MiB
NUMA node0 CPU(s):               0-3
Vulnerability Itlb multihit:     KVM: Mitigation: Split huge pages
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW,
                                             STIBP conditional, RSB filling
Vulnerability Srbds:             Vulnerable: No microcode
Vulnerability Tsx async abort:   Not affected
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
                                 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
                                 xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor
                                 ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2
                                 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm
                                 cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi
                                 flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat
                                 pln pts md_clear flush_l1d

Jak widać wyżej, na pozycji Virtualization: mamy VT-x , który to odpowiada, za wirtualizację w procesorach Intel.

Warto dodać w tym miejscu, że istnieje także narzędzie kvm-ok (dostępne w Debianie w pakiecie cpu-checker ), które jest w stanie zweryfikować wsparcie naszej maszyny dla wirtualizacji i po części też nakierować nas na prawidłowy trop w przypadku ewentualnych problemów:

# kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

Ustawienia BIOS/EFI/UEFI

Praktycznie wszystkie nowsze procesory (produkowane od ponad dekady) posiadają w standardzie wsparcie dla sprzętowej wirtualizacji. Jeśli jednak w pliku /proc/cpuinfo nie znajdziemy interesującej nas flagi, to jest niemal pewne, że wirtualizacja została wyłączona na poziomie EFI/UEFI lub BIOS (w zależności, które z nich posiadamy). W takim przypadku trzeba wejść w ustawienia BIOS/EFI/UEFI i włączyć stosowne opcje. Poniżej jest przykład z mojego ThinkPad'a T430:

virtualization-processor-bios-efi-uefi-kvm-qemu

Oczywiście nazwy opcji mogą się nieco różnić ale raczej nie powinniśmy mieć problemów z ustaleniem, które opcje w BIOS/EFI/UEFI odpowiadają za włączenie wirtualizacji.

Konfiguracja kernela linux pod QEMU/KVM

Standardowy kernel dystrybucji Debian zawiera praktycznie wszystkie niezbędne opcje, które muszą być włączone w konfiguracji jądra by wsparcie dla wirtualizacji było zapewnione. Nie trzeba zatem nic dodatkowo ustawiać. Ja jednak od dłuższego czasu buduję kernel dla swojego laptopa samodzielnie i do tej pory nie korzystałem na tym sprzęcie z dobrodziejstw jakie zapewniają maszyny wirtualne. Dlatego też wszystkie opcje kernela dotyczące mechanizmu wirtualizacji (z CONFIG_VIRTUALIZATION na czele) były wyłączone. Jeśli nasz kernel nie posiada wsparcia dla wirtualizacji i chcielibyśmy mu je dorobić, to musimy włączyć w nim te poniższe opcje:

CONFIG_VIRTUALIZATION
CONFIG_KVM

W zależności od posiadanego procesora (Intel/AMD), trzeba wybrać moduł dla KVM. Jeśli mamy procesor Intela, to dodatkowo zaznaczamy:

CONFIG_KVM_INTEL

Jeśli zaś mamy procesor AMD, to włączamy:

CONFIG_KVM_AMD

Możemy również włączyć obie te opcje ale taki stan rzeczy będzie powodował problemy w przypadku, gdy wkompilujemy te moduły bezpośrednio w jądro. Jeśli faktycznie potrzebujemy obu tych opcji (co raczej nie powinno mieć miejsca w przypadku budowania kernela dla konkretnej maszyny), to lepiej jest pozostawić je w formie modułów.

Poniższe parametry są opcjonalne ale mogą znacznie poprawić wydajność sieci maszyn wirtualnych:

CONFIG_VHOST=y
CONFIG_VHOST_MENU=y
CONFIG_VHOST_NET=y

Upewnijmy się też, że mamy zaznaczone te poniższe opcje, tak by nie było problemu z tworzeniem wirtualnych interfejsów mostka oraz interfejsów sieciowych maszyn wirtualnych:

CONFIG_NETDEVICES
CONFIG_NET_CORE
CONFIG_TUN
CONFIG_BRIDGE

Kernel 64-bit vs. 32-bit

Jeśli chodzi o wirtualizację, to powinniśmy korzystać z 64-bitowego kernela linux. Nie jest to co prawda wymagane ale jeśli chcemy mieć możliwość przydzielić maszynie wirtualnej więcej niż 2 GiB pamięci RAM, to nie damy rady tego uczynić jeśli na maszynie hosta mamy kernel 32-bit.

Warto tutaj zaznaczyć, że mając na maszynie hosta kernel 64-bitowy, w dalszym ciągu możemy tworzyć 32-bitowe maszyny wirtualne. W drugą stronę to nie zadziała, czyli mając 32-bitowy kernel na hoście jesteśmy ograniczeni jedynie do 32-bitowych maszyn wirtualnych.

Konfiguracja HugePages pod QEMU/KVM

Konfiguracja HugePages na potrzeby maszyn wirtualnych QEMU/KVM została opisana w osobnym artykule.

Potrzebne oprogramowanie

Możemy przejść do instalacji potrzebnego oprogramowania, które umożliwi nam tworzenie i zarządzanie maszynami wirtualnymi na naszym linux'ie. Poniżej znajduje się lista pakietów, które trzeba zainstalować w systemie:

# aptitude install \
         qemu-system-x86 qemu-system-gui qemu-utils qemu-system-modules-spice \
         libvirt-daemon libvirt-daemon-system virt-manager \
         bridge-utils dnsmasq-base iptables \
         gir1.2-spiceclientgtk-3.0

Pakiety qemu-system-x86 oraz qemu-kvm

W wielu miejscach na necie można się spotkać z instalacją w systemie pakietu qemu-kvm . Niemniej jednak, obecnie w Debianie (Sid) instalacja tego pakietu kończy się poniższym komunikatem:

# aptitude install qemu-kvm
The following NEW packages will be installed:
  qemu-kvm
0 packages upgraded, 1 newly installed, 0 to remove and 29 not upgraded.
Need to get 76.4 kB of archives. After unpacking 114 kB will be used.
The following packages have unmet dependencies:
 qemu-system-x86 : Breaks: qemu-kvm but 1:5.0-8 is to be installed
The following actions will resolve these dependencies:

     Keep the following packages at their current version:
1)     qemu-kvm [Not Installed]

Accept this solution? [Y/n/q/?]

Winny jest tutaj pakiet qemu-system-x86 , który to z kolei ma w swoich zależnościach:

Breaks:   qemu-kvm
Replaces: qemu-kvm
Provides: qemu-kvm, qemu-system-i386, qemu-system-x86-64

I to właśnie qemu-system-x86 powinien być instalowany w miejsce qemu-kvm .

Pakiet qemu-system-gui

Pakiet qemu-system-gui dostarcza z kolei lokalny graficzny interfejs użytkownika (GTK) oraz bakendy audio dla pełnej emulacji systemu (pakiety qemu-system-* , m.in. qemu-system-x86 , który będzie wykorzystywany w tym artykule).

Pakiet qemu-utils

W pakiecie qemu-utils znajduje się m.in. narzędzie qemu-img , które umożliwia operowanie na obrazach maszyn wirtualnych, wliczając w to zmianę ich rozmiaru czy kompresję danych, tak by te obrazy nie zajmowały niepotrzebnie zbyt dużo miejsca na dysku. Jeśli mamy zamiar operować na obrazach maszyn wirtualnych, to dobrze jest ten pakiet również sobie zainstalować.

Pakiety libvirt-daemon oraz libvirt-daemon-system

Pakiet libvirt-daemon dostarcza demona libvirtd zarządzającego mechanizmami wirtualizacji (QEMU, KVM, XEN, OpenVZ, LXC, oraz VirtualBox). Z kolei w pakiecie libvirt-daemon-system znajduje się konfiguracja dla demona libvirtd . Dodatkowo, pakiet libvirt-daemon-system pociąga w zależnościach również libvirt-daemon-system-systemd lub libvirt-daemon-system-sysv . W tym przypadku, jako że używany jest systemd, to libvirt-daemon-system-systemd zostanie zainstalowany. Ten pakiet zawiera jedynie zależności, które umożliwiają libvirt współpracowanie z systemd.

Pakiet virt-manager

W pakiecie virt-manager znajduje się aplikacja (w stadium eksperymentalnym) umożliwiająca graficzne zarządzanie maszynami wirtualnymi. W zasadzie każdy aspekt pracy związany z tworzeniem i zarządzaniem maszynami wirtualnymi (albo też ich ogromną część) można ogarnąć przy pomocy aplikacji virt-manager . Z tych ciekawszych rzeczy można jeszcze wspomnieć, że virt-manager posiada wbudowany klient SPICE/VNC.

Pakiety bridge-utils, dnsmasq-base i iptables

By nieco ułatwić konfigurację sieci, libvirt ma zdefiniowaną NAT'owską sieć 192.168.122.1/24 i wszystkie maszyny wirtualne domyślnie do tej sieci będą przypisane. By połączenie było realizowane za pomocą NAT, potrzebny będzie wirtualny interfejs mostka, którym to libvirt będzie zarządzał. Potrzebne są zatem stosowne narzędzia dostępne w pakiecie bridge-utils . Każda maszyna wirtualna otrzyma swój adres IP za pomocą protokołu DHCP, i do tego celu potrzebny będzie nam serwer DHCP, w roli którego wystąpi dnsmasq dostępny w Debianie w pakiecie dnsmasq-base . By komunikacja maszyn wirtualnych ze światem zewnętrznym przez sieci była możliwa, potrzebny będzie filtr pakietów iptables oraz odpowiednia jego konfiguracja.

Trzeba tutaj zaznaczyć, że ta domyślna sieć dla maszyn wirtualnych nie jest domyślnie włączona i nie jest obligatoryjne instalowanie któregokolwiek z tych trzech pakietów. Jeśli jednak chcielibyśmy korzystać z tych predefiniowanych ustawień sieci, to te pakiety trzeba doinstalować.

Kolejna sprawa, to sam filtr pakietów. Debian oraz inne dystrybucje linux'a przeszły jakiś czas temu z iptables na nftables . Jeśli wykorzystujemy narzędzie nft do konfiguracji zapory sieciowej, to ta domyślna konfiguracja sieci nie będzie kompatybilna i trzeba będzie ręcznie skonfigurować reguły, by sieć w maszynach wirtualnych działała jak należy (o tym później).

Pakiet gir1.2-spiceclientgtk-3.0

W przypadku, gdy podczas startu maszyny wirtualnej zobaczymy na ekranie komunikat Error connecting to graphical console: Error opening Spice console, SpiceClientGtk missing. , co wygląda mniej więcej tak:

virtualization-kvm-qemu-virt-manager-error-console

Oznacza to, że brakuje w systemie pakietu gir1.2-spiceclientgtk-3.0 .

Co co ciekawe, ja u siebie miałem zainstalowany pakiety spice-client-gtk , który ma w zależnościach gir1.2-spiceclientgtk-3.0 , a mimo to, ten powyższy błąd ciągle występował. Problem ustał dopiero po odinstalowaniu pakietu spice-client-gtk i bezpośrednim zainstalowaniu gir1.2-spiceclientgtk-3.0 . To tak na wypadek, gdyby ktoś miał podobny problem z uruchamianiem maszyn wirtualnych.

Pakiet qemu-system-modules-spice

Po postawieniu świeżego systemu, chcąc uruchomić jedną z moich maszyn wirtualnych okazało się, że taka akcja kończy się poniższym komunikatem:

Error starting domain: unsupported configuration: domain configuration does not support video model 'qxl'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
    ret = fn(self, *args, **kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1402, in startup
    self._backend.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1373, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: unsupported configuration: domain configuration does not support video model 'qxl'

Zainstalowanie pakietu qemu-system-modules-spice niweluje ten problem.

Grupy w linux a operowanie na maszynach wirtualnych

Po zainstalowaniu potrzebnego oprogramowania, w linux'ie powinny pojawić się dodatkowe grupy, tj. kvm , libvirt oraz libvirt-qemu . W wielu tutorialach poświęconych QEMU/KVM pojawiają się sugestie by dodać zwykłego użytkownika do każdej z tych trzech grup. Wygląda jednak na to, że nie jest to konieczne i do tego jeszcze może nieco zagrażać bezpieczeństwu systemu.

Jeżeli nie dodamy zwykłego użytkownika do żadnej z wyżej wymienionych grup, to np. przy uruchamianiu virt-manager (przy łączeniu się z demonem libvirtd ) będziemy ciągle pytani o hasło administratora:

virtualization-kvm-qemu-virt-manager-password

Grupa libvirt

By nie być pytanym o hasło za każdym razem jak będziemy uruchamiać virt-manager czy korzystać z narzędzia virsh (przykładowo virsh -c qemu:///system 'list --all' ), to musimy dodać zwykłego użytkownika do grupy libvirt :

# adduser morfik libvirt

Wymaga tego polityka policykit, która jest określona w pliku /usr/share/polkit-1/rules.d/60-libvirt.rules :

# cat /usr/share/polkit-1/rules.d/60-libvirt.rules
// Allow any user in the 'libvirt' group to connect to system libvirtd
// without entering a password.

polkit.addRule(function(action, subject) {
    if (action.id == "org.libvirt.unix.manage" &&
        subject.isInGroup("libvirt")) {
        return polkit.Result.YES;
    }
});

Grupa libvirt-qemu

Jeśli zaś chodzi o grupę libvirt-qemu , to systemowe procesy QEMU/KVM są uruchomione jako użytkownik/grupa libvirt-qemu (można ten aspekt dostosować w pliku /etc/libvirt/qemu.conf ), przez co szereg plików w katalogu /var/lib/libvirt/ posiada użytkownika/grupę libvirt-qemu :

# tree -fpugs /var/lib/libvirt/
/var/lib/libvirt
├── [drwx--x--x root     root            4096]  /var/lib/libvirt/boot
├── [drwxr-xr-x root     root            4096]  /var/lib/libvirt/dnsmasq
│   ├── [-rw-r--r-- root     root               0]  /var/lib/libvirt/dnsmasq/default.addnhosts
│   ├── [-rw------- root     root             598]  /var/lib/libvirt/dnsmasq/default.conf
│   ├── [-rw-r--r-- root     root               0]  /var/lib/libvirt/dnsmasq/default.hostsfile
│   ├── [-rw-r--r-- root     root              87]  /var/lib/libvirt/dnsmasq/virbr0.macs
│   └── [-rw-r--r-- root     root             211]  /var/lib/libvirt/dnsmasq/virbr0.status
├── [drwx--x--x root     root            4096]  /var/lib/libvirt/images
│   └── [-rw-r--r-- libvirt-qemu libvirt-qemu  4337762304]  /var/lib/libvirt/images/ubuntu20.04-small.qcow2
├── [drwxr-x--- libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu
│   ├── [drwxr-x--- libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu/channel
│   │   └── [drwxr-x--- libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu/channel/target
│   │       └── [drwxr-x--- libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu/channel/target/domain-19-ubuntu20.04
│   │           └── [srwxrwxr-x libvirt-qemu libvirt-qemu           0]  /var/lib/libvirt/qemu/channel/target/domain-19-ubuntu20.04/org.qemu.guest_agent.0
│   ├── [drwxr-xr-x libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu/checkpoint
│   ├── [drwxr-x--- libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu/domain-19-ubuntu20.04
│   │   ├── [-rw------- libvirt-qemu libvirt-qemu          32]  /var/lib/libvirt/qemu/domain-19-ubuntu20.04/master-key.aes
│   │   └── [srwxrwxr-x root     root               0]  /var/lib/libvirt/qemu/domain-19-ubuntu20.04/monitor.sock
│   ├── [drwxr-xr-x libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu/dump
│   ├── [drwxr-xr-x libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu/nvram
│   ├── [drwxr-xr-x libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu/ram
│   ├── [drwxr-xr-x libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu/save
│   └── [drwxr-xr-x libvirt-qemu libvirt-qemu        4096]  /var/lib/libvirt/qemu/snapshot
└── [drwx------ root     root            4096]  /var/lib/libvirt/sanlock

15 directories, 9 files

W katalogu /var/lib/libvirt/ są przechowywane obrazy maszyn wirtualnych, jak i również informacje o uruchomionych i aktualnie działających w systemie hosta maszynach wirtualnych. Zwykły użytkownik niekoniecznie powinien mieć swobodny dostęp do tych plików i standardowo go nie posiada i lepiej by tak zostało. Dlatego też lepiej nie dodawać zwykłego użytkownika do grupy libvirt-qemu .

Grupa kvm

Z kolei grupa kvm potrafi zapewnić zwykłym użytkownikom dostęp do urządzenia /dev/kvm , które jest niezbędne do uruchamiania maszyn wirtualnych na bazie KVM. UDEV nadaje stosowne uprawnienia urządzeniu /dev/kvm za pośrednictwem pliku /lib/udev/rules.d/50-udev-default.rules , który to ma określoną tę poniższą regułę:

KERNEL=="kvm", GROUP="kvm", MODE="0660", OPTIONS+="static_node=kvm"

Zatem dodanie użytkownika do grupy kvm sprawi, że będzie miał on dostęp (zapis/odczyt) do tego urządzenia. Niemniej jednak, w systemach mających na pokładzie systemd jest dostępny również plik /lib/udev/rules.d/70-uaccess.rules , który zawiera tę poniższą linijkę:

SUBSYSTEM=="misc", KERNEL=="kvm", TAG+="uaccess"

Ma ona dodany tag uaccess , który to jest używany przez logind do dynamicznego nadawania praw dostępu do określonych urządzeń lokalnym użytkownikom via ACL (Access Control List). Ta powyższa linijka dotyczy urządzenia /dev/kvm , przez co nie ma potrzeby ręcznego dodawania użytkownika do grupy kvm . Możemy się o tym przekonać wydając poniższe polecenia:

$ egrep kvm /etc/group
kvm:x:136:

$ getfacl /dev/kvm
getfacl: Removing leading '/' from absolute path names
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
user:morfik:rw-
group::rw-
mask::rw-
other::---

Zatem użytkownik morfik nie jest dodany do grupy kvm ale ma uprawnienia zapisu i odczytu urządzenia /dev/kvm .

Trzeba tutaj wyraźnie zaznaczyć, że dostęp do urządzenia /dev/kvm jest przyznany jedynie w przypadku, gdy sesja jest lokalna i do tego aktywna. Ten fakt możemy zweryfikować w poniższy sposób:

$ loginctl list-sessions
SESSION  UID USER   SEAT  TTY
      1 1000 morfik seat0 tty4

1 sessions listed.

$ loginctl show-session 1
...
Remote=no
Active=yes
...

Jeśli któryś z tych dwóch warunków nie zostanie spełniony, np. przejdziemy do konsoli TTY1 via CTRL+ALT+F1, to nasza sesja graficzna stanie się nieaktywna i dostęp do urządzenia /dev/kvm zostanie odebrany. Możemy się o tym przekonać logując się na TTY1 na innego użytkownika niż ten zalogowany w sesji graficznej (np. root) i ponownie wydając poniższe polecenie:

# getfacl /dev/kvm
getfacl: Removing leading '/' from absolute path names
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
group::rw-
mask::rw-
other::---

Nie ma już tutaj linijki z user:morfik:rw- , która była wcześniej. Oczywiście jak tylko powrócimy do sesji graficznej, to te uprawnienia automatycznie zostaną ponownie nadane.

Nadanie uprawnień zwykłemu użytkownikowi by mógł wejść w interakcję z urządzeniem /dev/kvm niezbędne jest jedynie w przypadku, gdy chcemy bezpośrednio korzystać z KVM. W tym artykule jednak wykorzystywany będzie głównie virt-manager , który to robi użytek z libvirt . W takim przypadku proces qemu-system-x86_64 jest uruchomiony jako użytkownik libvirt-qemu , którego to grupą główną jest kvm :

$ cat /etc/group | grep kvm
kvm:x:136:

$ cat /etc/passwd | grep 136
libvirt-qemu:x:64055:136:Libvirt Qemu,,,:/var/lib/libvirt:/usr/sbin/nologin

Dlatego też proces qemu-system-x86_64 będzie miał zawsze dostęp do urządzenia /dev/kvm , przez co my w zasadzie nie musimy dodawać swojego użytkownika do grupy kvm , o ile oczywiście zamierzamy korzystać (bezpośrednio lub pośrednio) z libvirt lub korzystamy z systemd.

Tworzenie maszyn wirtualnych QEMU/KVM

Przyszła już chyba najwyższa pora by wziąć się za same maszyny wirtualne. Niemniej jednak, przydałoby się pierw jakąś utworzyć. Do tego celu potrzebny nam będzie w zasadzie kawałek nośnika instalacyjnego -- tego samego, który zwykliśmy wykorzystywać do instalacji linux'a na regularnym desktopie czy laptopie. W tym przypadku został wykorzystany obraz Ubuntu 20.04. Po pobraniu stosownego pliku, odpalamy virt-manager i łączymy się z qemu:///system (domyślnie jest utworzony):

Następnie klikając w ikonkę monitora tworzymy maszynę wirtualną:

virtualization-kvm-qemu-virt-manager-create-machine

Wybieramy lokalne medium instalacyjne, tj. ten obraz ISO, który pobraliśmy wcześniej:

virtualization-kvm-qemu-virt-manager-create-machine

Jeśli wskazaliśmy jeden z tych bardziej popularnych obrazów ISO, to virt-manager powinien rozpoznać z jakim obrazem ma do czynienia:

virtualization-kvm-qemu-virt-manager-create-machine

Wstępnie też konfigurujemy przydział pamięci operacyjnej RAM oraz rdzeni procesora:

virtualization-kvm-qemu-virt-manager-create-machine

Następnie wybieramy format obrazu maszyny wirtualnej oraz ilość przestrzeni dyskowej, którą będzie ta maszyna mogła wykorzystać. Jeśli nie chcemy tworzyć obrazów maszyn wirtualnych na partycji systemowej w katalogu /var/lib/libvirt/images/ , to musimy zdefiniować lokalizację ręcznie:

virtualization-kvm-qemu-virt-manager-create-machine

Klikamy teraz w ten zielony plusik obok Volumes , dodajemy nowy obraz w formacie .qcow2 i określamy jego rozmiar:

virtualization-kvm-qemu-virt-manager-create-machine

Następnie wybieramy tak utworzony obraz maszyny wirtualnej:

virtualization-kvm-qemu-virt-manager-create-machine

Pozostał nam ostatni krok, tj. nazwanie maszyny wirtualnej i przypisanie jej do konkretnej sieci. Standardowe ustawienia sieci powinny wystarczyć chyba, że korzystamy z nftables . W takim przypadku trzeba będzie nieco przerobić domyślną sieć lub utworzyć nową "otwartą":

virtualization-kvm-qemu-virt-manager-create-machine

Warto też zaznaczyć opcję Customize configuration before install , co pozwoli nam skonfigurować wstępnie maszynę wirtualną zanim rozpocznie się proces instalacji systemu operacyjnego.

Instalacja systemu operacyjnego maszyny wirtualnej

Po wstępnym skonfigurowaniu parametrów maszyny wirtualnej możemy w końcu już puścić instalację systemu operacyjnego, który w tej maszynie będzie działał. Zapisujemy zatem wszystkie ustawienia (jeśli jeszcze tego nie zrobiliśmy) i wciskamy przycisk Begin Installation . Chwilę po jego przyciśnięciu, powinniśmy zobaczyć znajome okienko instalacji Ubuntu: