Product SiteDocumentation Site

12.2. virtualisering

Virtualisering er et av de viktigste fremskritt i de seneste årenes datautvikling. Begrepet omfatter ulike abstraksjoner og teknikker som simulerer virtuelle datamaskiner med varierende grad av uavhengighet på selve maskinvaren. En fysisk tjener kan så være vert for flere systemer som arbeider samtidig, og i isolasjon. Bruksområdene er mange, og utledes ofte fra denne isolasjon: for eksempel testmiljøer med varierende konfigurasjoner, eller separasjon av vertsbaserte tjenester mellom ulike virtuelle maskiner for sikkerheten.
Det er flere virtualiseringsløsninger, hver med sine egne fordeler og ulemper. Denne boken vil fokusere på Xen, LXC, og KVM, mens andre viktige implementeringer omfatter de følgende:

12.2.1. Xen

Xen er en «paravirtualiserings»-løsning. Den introduserer et tynt abstraksjonslag, kalt en «hypervisor», mellom maskinvaren og de øvre systemer; dette fungerer som en dommer som kontrollerer tilgangen til maskinvaren fra de virtuelle maskinene, men den håndterer bare noen av instruksjonene, resten kjøres direkte av maskinvaren på vegne av systemene. Den største fordelen er at prestasjonen ikke blir dårligere, og systemer kjører med nær sin opprinnelige hastighet; ulempen er at operativsystemkjernene man ønsker å bruke på en Xen-hypervisor, trenger tilpasning for å kjøre på Xen.
La oss bruke litt tid på vilkår. Hypervisoren er det nederste laget, som kjører direkte på maskinvaren, selv under kjernen. Denne hypervisor kan dele resten av programvaren over flere domener, som kan sees på som så mange virtuelle maskiner. En av disse domenene (den første som blir startet) er kjent som dom0, og har en spesiell rolle, siden bare dette domenet kan kontrollere hypervisor, og kjøring av andre domener. Disse andre domener er kjent somdomU. Med andre ord, og fra et brukersynspunkt, samsvarer dom0-et med «verten» i andre visualiseringssystemer, mens en domU kan bli sett på som en «gjest».
Å bruke Xen under Debian krever tre komponenter:
  • Hypervisoren selv. Etter tilgjengelig maskinvare, vil den aktuelle pakken være enten xen-hypervisor-4.4-amd64, xen-hypervisor-4.4-armhf, eller xen-hypervisor-4.4-arm64.
  • En kjerne som kjører på den aktuelle hypervisoren. Enhver kjerne nyere enn 3.0 vil gjøre det, inkludert 3.16 versjon i Jessie.
  • i386-arkitekturen krever også et standard bibliotek med de riktige oppdateringer som drar nytte av Xen; dette er i libc6-xen-pakken.
For å unngå å måtte velge disse komponentene for hånd, er noen hjelpepakker tilgjengelige (for eksempel xen-linux-system-amd64). De trekker alle inn en kjent, god kombinasjon med de aktuelle hypervisor- og kjernepakkene. Hypervisoren har også med xen-utils-4.4, som inneholder verktøy for å kontrollere hypervisoren fra Dom0. Dette bringer i sin tur det aktuelle standard biblioteket. Under installasjonen av alt dette, lager også konfigurasjonsskriptene en ny oppføring i Grub oppstartsmenyen, slik som å starte den valgte kjernen i en Xen Dom0. Merk imidlertid at denne inngangen vanligvis er satt som den første på listen, og vil derfor bli valgt som standard. Hvis det ikke er ønsket, vil følgende kommandoer endre det:
# mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen
# update-grub
Når disse nødvendigheter er installert, er neste skritt å teste hvordan Dom0 selv virker. Dette innebærer omstart for hypervisoren og Xen-kjernen. Systemet skal starte på vanlig måte, med noen ekstra meldinger på konsollen under de tidlige initialiseringstrinnene.
Nå er det faktisk på tide å installere nyttige systemer på DomU-systemene med verktøy fra xen-tools. Denne pakken leverer xen-create-image-kommandoen, som i stor grad automatiserer oppgaven. Den eneste nødvendige parameteren er --hostname, som gir navn til DomU-en. Andre valg er viktige, men de kan lagres i /etc/xen-tools/xen-tools.conf-konfigurasjonsfilen, og fraværet deres fra kommandolinjen utløser ikke en feil. Det er derfor viktig å enten sjekke innholdet i denne filen før du oppretter bilder, eller å bruke ekstra parametre i bruken av xen-create-image. Viktige parametre omfatter de følgende:
  • --memory, for å spesifisere hvor mye RAM som er øremerket til det systemet som nettopp er laget;
  • --size og --swap, for å definere størrelsen på de «virtuelle disker» som er tilgjengelig for DomU-en;
  • --debootstrap, for å få det nye systemet til å bli installert med debootstrap; i det tilfellet vil også --dist-valget oftest bli brukt (med et distribusjonsnavn som jessie).
  • --dhcp sier at DomUs nettverkskonfigurasjon skal skaffes av DHCP, mens --ip tillater å definere en statisk IP-adresse.
  • Til slutt må lagringsmetode velges for bildet som skal opprettes (de som vil bli sett på som harddisker fra DomU). Den enkleste metoden, tilsvarende --dir-valget, er å opprette en fil på Dom0 for hver enhet der DomU skal være. For systemer som bruker LVM, er alternativet å bruke --lvm-valget, fulgt av navnet på en volumgruppe; xen-create-image vil deretter opprette et nytt logisk volum inne i den gruppen, og dette logiske volumet vil bli tilgjengelig for DomU-et som en harddisk.
Så snart disse valgene er gjort, kan vi lage bildet til vår fremtidige Xen-DomU:
# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=jessie --role=udev

[...]
General Information
--------------------
Hostname       :  testxen
Distribution   :  jessie
Mirror         :  http://ftp.debian.org/debian/
Partitions     :  swap            128Mb (swap)
                  /               2G    (ext3)
Image type     :  sparse
Memory size    :  128Mb
Kernel path    :  /boot/vmlinuz-3.16.0-4-amd64
Initrd path    :  /boot/initrd.img-3.16.0-4-amd64
[...]
Logfile produced at:
         /var/log/xen-tools/testxen.log

Installation Summary
---------------------
Hostname        :  testxen
Distribution    :  jessie
MAC Address     :  00:16:3E:8E:67:5C
IP-Address(es)  :  dynamic
RSA Fingerprint :  0a:6e:71:98:95:46:64:ec:80:37:63:18:73:04:dd:2b
Root Password   :  adaX2jyRHNuWm8BDJS7PcEJ
Vi har nå en virtuell maskin, men den kjører ikke for øyeblikket (og bruker derfor bare plass på harddisken til Dom0). Selvfølgelig kan vi skape flere bilder, kanskje med ulike parametere.
Før du slår disse virtuelle maskinene på, må vi definere tilgangen deres. De kan selvfølgelig sees som isolerte maskiner, som bare nås gjennom sine systemkonsoller. Men dette samsvarer sjelden med bruksmønsteret. Mesteparten av tiden blir en DomU betraktet som en ekstern tjener, og kun tilgjengelig gjennom et nettverk. Det vil være ganske upraktisk å legge til et nettverkskort for hver DomU; som er grunnen til at Xen tillater å lage virtuelle grensesnitt, som hvert domene kan se og bruke som standard. Merk at disse kortene, selv om de er virtuelle, bare vil være nyttige så snart de er koblet til et nettverk, selv et virtuelt et. Xen har flere nettverksmodeller for det:
  • Den enkleste er bridge-modellen. Alle eth0-nettverkskort (både i Dom0- og DomU-systemer) oppfører seg som om de var direkte koblet til en Ethernet-svitsj.
  • Så følger routing-modellen, hvor Dom0 oppfører seg som en ruter som står mellom DomU-systemer og det (fysiske) eksterne nettverket.
  • Til slutt, i NAT-modellen, der Dom0 igjen er mellom DomU-systemene og resten av nettverket, men DomU-systemene er ikke direkte tilgjengelig utenfra, og trafikken går gjennom noen nettverksadresseoversettelser på Dom0-et.
Disse tre nettverksnodene innebefatter en rekke grensesnitt med uvanlige navn, for eksempel vif*, veth*, peth* og xenbr0. Xen-hypervisoren setter dem opp, uansett med hvilken layout de er definert i, under kontroll av verktøyet for brukerrom. Siden NAT- og rutingmodellene bare er tilpasset det enkelte tilfelle, vil vi bare omhandle brobyggingsmodellen.
Standardkonfigurasjon av Xen-pakkene endrer ikke hele systemets nettverksoppsett. Men xend-nissen er konfigurert for å integrere inn virtuelle nettverksgrensesnitt i alle tilstedeværende nettverksbroer (der xenbr0 tar forrang dersom flere slike broer finnes). Vi må derfor sette opp en bro i /etc/network/interfaces (som krever installasjon av bridge-utils-pakken, som er grunnen til at xen-utils-4.4-pakken anbefaler den) for å erstatte den eksisterende eth0-inngangen:
auto xenbr0
iface xenbr0 inet dhcp
    bridge_ports eth0
    bridge_maxwait 0
Etter omstart, for å sørge for at brua blir opprettet automatisk, kan vi nå starte DomU med Xen-kontrollverktøyet, spesielt xl-kommandoen. Denne kommandoen tillater ulike håndteringer av domenene, inkludert å føre dem opp, og starte/stoppe dem.
# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   463     1     r-----      9.8
# xl create /etc/xen/testxen.cfg
Parsing config from /etc/xen/testxen.cfg
# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   366     1     r-----     11.4
testxen                                      1   128     1     -b----      1.1
Merk at testxen-DomU bruker virkelig minne tatt fra RAM som ellers ville være tilgjengelig for Dom0, og ikke simulert minne. Når du bygger en tjener som skal være vert for Xen-bruk, pass på å sette av tilstrekkelig fysisk RAM.
Se der! Vår virtuelle maskin starter opp. Vi får tilgang til den i en av to modi. Den vanlige måten er å koble seg til «eksternt» gjennom nettverket, slik som vi ville koble til en ekte maskin; Det vil som regel enten kreve oppsett av en DHCP-tjener, eller en DNS-konfigurasjon. Den andre måten, som kan være den eneste måten hvis nettverkskonfigurasjonen var feil, er å bruke hvc0-konsollet, med xl console-kommandoen:
# xl console testxen
[...]

Debian GNU/Linux 8 testxen hvc0

testxen login: 
Man kan så åpne en sesjon, akkurat som man ville gjøre hvis du sitter med den virtuelle maskinens tastatur. Frakobling fra denne konsollen oppnås med Control+]-tastekombinasjon.
Når DomU kjører, kan den brukes akkurat som en hvilken som helst annen tjener (siden den er et GNU/Linux-system tross alt). Imidlertid tillater den virtuelle maskinstatusen noen ekstra funksjoner. For eksempel kan en DomU midlertidig stoppes, og så begynne igjen, med xl pause, og xl unpause-kommandoer. Merk at selv om DomU i pause ikke bruker noen prosessorkraft, er det tildelte minne fortsatt i bruk. Det kan være interessant å vurdere xl save og xl restorekommandoene: Å spare en DomU frigjør ressursene den tidligere brukte, inkludert RAM. Når gjenopptatt (eller avpauset, for den saks skyld), legger ikke DomU en gang merke til noe utover tiden som går. Hvis en DomU var i gang når Dom0 er stengt, lagrer skriptpakken automatisk DomU-et, og gjenopprette den ved neste oppstart. Dette vil selvfølgelig medføre at de inntrufne standard ubekvemmelighetene påløper når en bærbar datamaskin settes i dvalemodus. For eksempel, spesielt hvis DomU er suspendert for lenge, kan nettverkstilkoblinger utløpe. Merk også at Xen så langt er uforenlig med en stor del av ACPI-strømstyring, noe som utelukker suspensjon av vert-(Dom0)systemet.
Stanse eller restarte en DomU kan gjøres enten fra DomU-et (med shutdown command) eller fra Dom0, med xl shutdown, eller xl reboot.

12.2.2. LXC

Selv om den brukes til å bygge «virtuelle maskiner», er LXC strengt tatt ikke et virtualiseringssystem, men et system for å isolere grupper av prosesser fra hverandre, selv om de alle kjører på den samme verten. Den trekker veksler på et sett av nyere utviklinger i Linux-kjernen, velkjent som kontrollgrupper, der forskjellige sett med prosesser som kalles «grupper» har forskjellige visninger av forskjellige aspekter ved det totale systemet. Mest kjent blant disse aspektene er prosessidentifikatorene, nettverkskonfigurasjonene og monteringspunktene. En slik gruppe av isolerte prosesser vil ikke ha noen adgang til de andre prosesser i systemet, og gruppens adgang til filsystemet kan være begrenset til en spesifikk undergruppe. Den kan også ha sitt eget nettverksgrensesnitt og rutingstabell, og den kan være konfigurert til å bare se et delsett av de tilgjengelige verktøy som finnes i systemet.
Disse funksjonene kan kombineres for å isolere en hel prosessfamilie som starter fra init-prossessen, og det resulterende settet ser mye ut som en virtuell maskin. Det offisielle navnet på et slikt oppsett er en «beholder» (derav LXC-forkortelsen:LinuX Containers), men en ganske viktig forskjell til «ekte» virtuelle maskiner, som leveres av Xen eller KVM, er at det ikke er noen andrekjerne; beholderen bruker den samme kjernen som vertssystemet. Dette har både fordeler og ulemper: Fordelene inkluderer utmerket ytelse grunnet total mangel på ekstrabelastning, og det faktum at kjernen har full oversikt over alle prosesser som kjører på systemet, slik at planleggingen kan være mer effektiv enn hvis to uavhengige kjerner skulle planlegge ulike oppgavesett. Den største blant ulempene er at det er umulig å kjøre en annen kjerne i en beholder (enten en annen Linux-versjon, eller et annet operativsystem i det hele tatt).
Siden vi har å gjøre med isolasjon, og ikke vanlig virtualisering, er å sette opp LXC-beholdere mer komplisert enn bare å kjøre en Debian-installer på en virtuell maskin. Vi vil beskrive noen forutsetninger, og deretter gå videre til nettverkskonfigurasjonen. Da vil vi faktisk være i stand til å lage systemet som skal kjøres i beholderen.

12.2.2.1. Innledende skritt

Pakken lxc inneholder de verktøyene som kreves for å kjøre LXC, og må derfor være installert.
LXC krever også oppsettssystemet kontrollgrupper, som er et virtuelt filsystem til å monteres på /sys/fs/cgroup. Ettersom Debian 8 byttet til systemd, som også er avhengig av kontrollgrupper, gjøres dette nå automatisk ved oppstart uten ytterligere konfigurasjon.

12.2.2.2. Nettverksoppsett

Målet med å installere LXC er å sette opp virtuelle maskiner; mens vi selvfølgelig kan holde dem isolert fra nettverket, og bare kommunisere med dem via filsystemet, innebærer de fleste brukstilfeller i det minste å gi minimal nettverkstilgang til beholderne. I det typiske tilfellet vil hver beholder få et virtuelt nettverksgrensesnitt koblet til det virkelige nettverket via en bro. Dette virtuelle grensesnittet kan kobles enten direkte på vertens fysiske nettverksgrensesnitt (der beholderen er direkte på nettverket), eller på et annet virtuelt grensesnitt som er definert hos verten (og verten kan da filtrere eller rute trafikk). I begge tilfelle kreves bridge-utils-pakken.
Det enkle tilfellet gjelder bare redigering /etc/network/interfaces, å flytte oppsettet for det fysiske grensesnittet (for eksempel eth0) til et brogrensesnitt (vanligvis br0), og konfigurere koblingen mellom dem. For eksempel, hvis nettverkskonfigurasjonsfilen i utgangspunktet inneholder oppføringer som de følgende:
auto eth0
iface eth0 inet dhcp
Bør de deaktiveres og erstattes med følgende:
#auto eth0
#iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
  bridge-ports eth0
Effekten av denne konfigurasjonen vil ligne på hva som ville blitt oppnådd dersom beholderne var maskiner koblet til det samme fysiske nettverket som vert. Bro-konfigurasjon (“bridge”-konfigurasjonen) håndterer transitt av Ethernet-rammer mellom alle bro-grensesnitt som inkluderer fysisk eth0, samt grensesnittet definert for beholderne.
I tilfeller der denne konfigurasjonen ikke kan brukes (for eksempel hvis ingen offentlige IP-adresser kan tildeles beholderne), blir et virtuelt tap-grensesnitt opprettet og koblet til broen. Den tilsvarende nettverkssammenhengen blir da som en vert med et andre nettverkskort koblet til en egen bryter, med også beholderne koblet til denne bryteren. Verten fungerer da som en inngangsport for beholdere hvis de er ment å kommunisere med omverdenen.
I tillegg til bridge-utils, krever denne «rike» konfigurasjonen vde2-pakken; /etc/network/interfaces-filen blir da:
# Interface eth0 is unchanged
auto eth0
iface eth0 inet dhcp

# Virtual interface 
auto tap0
iface tap0 inet manual
  vde2-switch -t tap0

# Bridge for containers
auto br0
iface br0 inet static
  bridge-ports tap0
  address 10.0.0.1
  netmask 255.255.255.0
Nettverket kan så bli satt opp enten statisk i beholderne, eller dynamisk med en DHCP-tjener som kjører hos verten. En slik DHCP-tjener må konfigureres til å svare på spørsmål om br0-grensesnittet.

12.2.2.3. Å sette opp systemet

La oss nå sette opp filsystemet som skal brukes av beholderen. Siden denne «virtuelle maskinen» ikke vil kjøres direkte på maskinvare, er noen finjusteringer nødvendige sammenlignet med et standard filsystem, spesielt så langt som kjernen, enheter og konsollene angår. Heldigvis inkluderer lxc skript som stort sett automatiserer denne konfigurasjonen. For eksempel vil følgende kommandoer (som krever debootstrap og rsync-packages) installere en Debian beholder:
root@mirwiz:~# lxc-create -n testlxc -t debian
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-jessie-amd64 ... 
Downloading debian minimal ...
I: Retrieving Release 
I: Retrieving Release.gpg 
[...]
Download complete.
Copying rootfs to /var/lib/lxc/testlxc/rootfs...
[...]
Root password is 'sSiKhMzI', please change !
root@mirwiz:~# 
Merk at filsystemet opprinnelig er opprettet i /var/cache/lxc, og deretter flyttet til den katalogen filsystemet skal til. Dette gjør det mulig å lage identiske beholdere mye raskere, ettersom det da bare kreves kopiering.
Merk at Debian-skriptet, for å opprette maler, godtar et --arch-valg for å spesifisere arkitekturen til systemet som skal installeres, og et --release-valg hvis du ønsker å installere noe annet enn den nåværende stabile utgaven av Debian. Du kan også sette omgivelsesvariabelen MIRROR til å peke på et lokalt Debian speil.
Nå inneholder det nyopprettede filsystemet et minimalt Debian-system, og som standard har ikke beholderen nettverksgrensesnitt (utover filmonteringen). Siden dette ikke er virkelig ønsket, vil vi endre beholderens konfigurasjonsfil (/var/lib/lxc/testlxc/config), og legge til noen få lxc.network.*-innganger:
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.hwaddr = 4a:49:43:49:79:20
Disse oppføringene betyr, henholdsvis, at et virtuelt grensesnitt vil bli opprettet i beholderen; at det automatisk vil bli vist når det blir meldt at beholderen er startet; at det automatisk vil bli koblet til br0-broen hos verten; og at MAC-adressen vil være som spesifisert. Skulle denne siste posten mangle eller være deaktivert, vil det genereres en tilfeldig MAC-adresse.
En annen nyttig inngang i den filen er innstillingen for vertsnavnet:
lxc.utsname = testlxc

12.2.2.4. Å starte beholderen

Nå som vårt virtuelle maskinbilde er klart, la oss starte beholderen:
root@mirwiz:~# lxc-start --daemon --name=testlxc
root@mirwiz:~# lxc-console -n testlxc
Debian GNU/Linux 8 testlxc tty1

testlxc login: root
Password: 
Linux testlxc 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@testlxc:~# ps auxwf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.2  28164  4432 ?        Ss   17:33   0:00 /sbin/init
root        20  0.0  0.1  32960  3160 ?        Ss   17:33   0:00 /lib/systemd/systemd-journald
root        82  0.0  0.3  55164  5456 ?        Ss   17:34   0:00 /usr/sbin/sshd -D
root        87  0.0  0.1  12656  1924 tty2     Ss+  17:34   0:00 /sbin/agetty --noclear tty2 linux
root        88  0.0  0.1  12656  1764 tty3     Ss+  17:34   0:00 /sbin/agetty --noclear tty3 linux
root        89  0.0  0.1  12656  1908 tty4     Ss+  17:34   0:00 /sbin/agetty --noclear tty4 linux
root        90  0.0  0.1  63300  2944 tty1     Ss   17:34   0:00 /bin/login --     
root       117  0.0  0.2  21828  3668 tty1     S    17:35   0:00  \_ -bash
root       268  0.0  0.1  19088  2572 tty1     R+   17:39   0:00      \_ ps auxfw
root        91  0.0  0.1  14228  2356 console  Ss+  17:34   0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102
root       197  0.0  0.4  25384  7640 ?        Ss   17:38   0:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.e
root       266  0.0  0.1  12656  1840 ?        Ss   17:39   0:00 /sbin/agetty --noclear tty5 linux
root       267  0.0  0.1  12656  1928 ?        Ss   17:39   0:00 /sbin/agetty --noclear tty6 linux
root@testlxc:~# 
Nå er vi i beholderen; vår tilgang til prosessene er begrenset til bare dem som er startet fra beholderen selv, og vår tilgang til filsystemet er tilsvarende begrenset til den øremerkede undergruppen i hele filsystemet (/var/lib/lxc/testlxc/rootfs). Vi kan gå ut av konsollet med Control+a q.
Legg merke til at vi kjørte beholderen som en bakgrunnsprosess, takket være --daemon-valget til lxc-start. Vi kan avbryte beholderen med en kommando slik som lxc-stop --name=testlxc.
Pakken lxc inneholder et initialiseringsskript som automatisk kan starte en eller flere beholdere når verten starter opp (det er avhengig av lxc-autostart som starter beholdere der lxc.start.auto-valget er satt til 1). Mer finkornet kontroll over oppstartsrekkefølgen er mulig med lxc.start.order og lxc.group. Som standard starter klargjøringsskriptet først beholdere som er en del av onboot-gruppen, og deretter beholdere som ikke er en del av en gruppe. I begge tilfeller er rekkefølgen innenfor en gruppe definert av lxc.start.order-valget.

12.2.3. Virtualisering med KVM

KVM, som står for Kernel-based Virtual Machine, er først og fremst en kjernemodul som gir det meste av infrastrukturen som kan brukes av en visualiserer, men er ikke selv en visualiserer. Faktisk kontroll av visualiseringen håndteres av en QEMU-basert applikasjon. Ikke være bekymret om denne seksjonen nevner qemu-*-kommandoer, den handler fremdeles om KVM.
I motsetning til andre visualiseringssystemer, ble KVM fusjonert inn i Linux-kjernen helt fra starten. Utviklerne valgte å dra nytte av prosessorens instruksjonssett øremerket til visualisering (Intel-VT og AMD-V), som holder KVM lett, elegant og ikke ressurskrevende. Motstykket, selvfølgelig, er at KVM ikke fungerer på alle datamaskiner, men bare på dem med riktige prosessorer. For x86-datamaskiner kan du bekrefte at du har en slik prosessor ved å se etter «vmx» eller «svm» i CPU-flagg oppført i /proc/cpuinfo.
Med Red Hats aktive støtte til utviklingen, har KVM mer eller mindre blitt referansen for Linux-virtualisering.

12.2.3.1. Innledende skritt

I motsetning til verktøy som VirtualBox, har KVM selv ikke noe brukergrensesnitt for å opprette og administrere virtuelle maskiner. Pakken qemu-kvm gir bare en kjørbar som kan starte en virtuell maskin, samt et initialiseringsskript som laster de aktuelle kjernemodulene.
Heldigvis gir Red Hat også et annet sett med verktøy for å løse dette problemet ved utvikling av libvirt-bibliotektet og de tilhørende virtual machine manager-verktøyene. libvirt kan administrere virtuelle maskiner på en enhetlig måte, uavhengig av virtualiseringen bak i kulissene (det støtter for tiden QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare og UML). virtual-manager er et grafisk grensesnitt som bruker libvirt til å opprette og administrere virtuelle maskiner.
Vi installerer først de nødvendige pakker med apt-get install qemu-kvm libvirt-bin virtinst virt-manager virt-viewer. libvirt-bin gir libvirtd-nissen, som tillater (potensielt ekstern) håndtering av virtuelle maskiner som kjører på verten, og starter de nødvendige VM-er når verten starter opp. I tillegg gir denne pakken virsh-kommandolinjeverktøy som gjør det mulig å styre libvirtd-håndterte maskiner.
Pakken virtinst leverer virt-install, som tillater å lage virtuelle maskiner fra kommandolinjen. Avslutningsvis gir virt-viewer tilgang til en VM-grafiske konsoll.

12.2.3.2. Nettverksoppsett

Akkurat som i Xen og LXC, innebærer den hyppigste nettverkskonfigurasjon en bro som grupperer nettverksgrensesnittene og de virtuelle maskinene (se Seksjon 12.2.2.2, «Nettverksoppsett»).
Alternativt, og i standardkonfigurasjonen levert av KVM, er den virtuelle maskinen tildelt en privat adresse (i 192.168.122.0/24-området), og NAT er satt opp slik at VM kan få tilgang til nettverket utenfor.
Resten av denne seksjonen forutsetter at verten har et eth0 fysisk grensesnitt, og en br0-bro, og den første er knyttet til den siste.

12.2.3.3. Installasjon med virt-install

Å lage en virtuell maskin er svært lik å installere et normalt system, bortsett fra at den virtuelle maskinens egenskaper er beskrevet i en tilsynelatende uendelig kommandolinje.
I praksis betyr dette at vi vil bruke Debians installasjonsprogram ved å starte den virtuelle maskinen på en virtuell DVD-ROM-stasjon som er tilordnet til et Debian DVD-bilde som ligger hos vertsystemet. VM vil eksportere sin grafiske konsoll over VNC-protokollen (se Seksjon 9.2.2, «Å bruke eksterne grafiske skrivebord» for detaljer), som tillater oss å kontrollere installasjonsprosessen.
Vi må først fortelle libvirtd hvor diskbildene skal lagres, med mindre standardplasseringen (/var/lib/libvirt/images/) er grei.
root@mirwiz:~# mkdir /srv/kvm
root@mirwiz:~# virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created

root@mirwiz:~# 
La oss nå starte installasjonsprosessen for den virtuelle maskinen, og ta en nærmere titt på de viktigste valgene til virt-install. Denne kommandoen registrerer den virtuelle maskinen med parametre i libvirtd, og starter den deretter slik at installasjonen kan fortsette.
# virt-install --connect qemu:///system  1
               --virt-type kvm           2
               --name testkvm            3
               --ram 1024                4
               --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10 5
               --cdrom /srv/isos/debian-8.1.0-amd64-netinst.iso  6
               --network bridge=br0      7
               --vnc                     8
               --os-type linux           9
               --os-variant debianwheezy

Starting install...
Allocating 'testkvm.qcow'             |  10 GB     00:00
Creating domain...                    |    0 B     00:00
Guest installation complete... restarting guest.

1

Valget --connect spesifiserer «hypervisoren» som skal brukes. Den har samme format som en URL som inneholder et virtualiseringssystem (xen://, qemu://, lxc://, openvz://, vbox://, og så videre), og den maskinen som skal være vert for VM (dette kan være tomt når det gjelder den lokale verten). I tillegg til det, og i QEMU/KVM tilfellet, kan hver bruker administrere virtuelle maskiner som arbeider med begrensede tillatelser, og URL-banen tillater å skille «system»-maskiner (/system) fra andre (/session).

2

Siden KVM forvaltes på samme måte som QEMU, tillater --virt-type kvm å spesifisere bruken av KVM selv om nettadressen ser ut som QEMU.

3

Valget V--name definerer et (unikt) navn for den virtuelle maskinen.

4

Valget --ram kan spesifisere hvor mye RAM (i MB) som skal avsettes til den virtuelle maskinen.

5

--disk angir plasseringen av bildefilen som skal representere harddisken til vår virtuelle maskinen; denne filen er laget, hvis den ikke allerede er til stede, med størrelsen (i GB) spesifisert av size-parameteret. format-parameteret gjør det mulig å velge mellom flere måter for lagring av bildefilen. Standardformatet (raw) er en enkelt fil som samsvarer nøyaktig med diskens størrelse og innhold. Vi plukket ut et avansert format her, spesifikk for QEMU, og tillater starting med en liten fil som bare vokser når den virtuelle maskinen faktisk begynner å bruke plass.

6

--cdrom-valget brukes til å indikere hvor en finner den optiske disken til bruk ved installasjon. Banen kan enten være en lokal bane for en ISO-fil, en URL der man kan få tak i filen, eller fra disk-filen i en fysisk CD-ROM-stasjon (dvs. /dev/cdrom).

7

--network angir hvordan det virtuelle nettverkskortet integreres i vertens nettverksoppsett. Standard oppførsel (som vi eksplisitt håndhevet/tvang i vårt eksempel) er å integrere det inn i hvilken som helst foreliggende nettverksbro. Hvis en slik bro ikke finnes, vil den virtuelle maskinen kun nå det fysiske nettverket gjennom NAT, så det får en adresse i et privat delnettsområde (192.168.122.0/24).

8

--vnc sier at den grafiske konsollen skal gjøres tilgjengelig ved hjelp av VNC. Standard virkemåte for den tilknyttede VNC-tjeneren er å bare lytte til det lokale grensesnitt; hvis VNC-klienten skal kjøres på en annen vert, krever opprettelse av forbindelsen at det settes opp en SSH-tunnel (se Seksjon 9.2.1.3, «Å lage krypterte tunneler med portvideresending (Port Forwarding)»). Alternativt kan --vnclisten=0.0.0.0 anvendes slik at VNC-tjeneren er tilgjengelig fra alle grensesnitt. Vær oppmerksom på at hvis du gjør det, må du virkelig sette opp din brannmur tilsvarende .

9

--os-type og --os-variant-valgene kan optimalisere noen parametere for den virtuelle maskinen, basert på noen av de kjente funksjonene i operativsystemet nevnt der.
Nå kjører den virtuelle maskinen, og vi må koble til den grafiske konsollen for å fortsette med installasjonen. Hvis den forrige operasjonen ble kjørt fra et grafisk skrivebordsmiljø, bør denne forbindelsen startes automatisk. Hvis ikke, eller hvis vi operere eksternt, kan virt-viewer kjøres fra et hvilket som helst grafisk miljø for å åpne den grafiske konsollen (merk at det spørres om rot-passordet til den eksterne verten to ganger, fordi operasjonen krever 2 SSH-forbindelser):
$ virt-viewer --connect qemu+ssh://root@server/system testkvm
root@server's password: 
root@server's password: 
Når installasjonsprosessen er ferdig, blir den virtuelle maskinen startet på nytt, nå klar til bruk.

12.2.3.4. Å håndtere maskiner med virsh

Nå som installasjonen er ferdig, la oss se hvordan man skal håndtere de tilgjengelige virtuelle maskinene. Det første du må prøve, er å spørre libvirtd om listen over de virtuelle maskinene den forvalter:
# virsh -c qemu:///system list --all
 Id Name                 State
----------------------------------
  - testkvm              shut off
La oss starte vår test av den virtuell maskinen:
# virsh -c qemu:///system start testkvm
Domain testkvm started
Vi kan nå få tilkoblingsinstruksjonene til det grafiske konsollet (den returnerte VNC-skjermen kan gis som parameter til vncviewer):
# virsh -c qemu:///system vncdisplay testkvm
:0
Andre tilgjengelige underkommandoer inkluderer virsh:
  • reboot for å restarte en virtuell maskin;
  • shutdown for å utløse en ren avslutning;
  • destroy, for å stoppe den brutalt;
  • suspend for å pause den;
  • resume for å avslutte pause;
  • autostart for å aktivere (eller deaktivere, med --disable-valget) automatisk start av den virtuelle maskinen når verten starter;
  • undefine for å fjerne alle spor etter den virtuelle maskinen fra libvirtd.
Alle disse underkommandoene tar en virtuell maskins identifikator som et parameter.

12.2.3.5. Å installere et RPM-basert system i Debian med yum

Hvis den virtuelle maskinen er ment til å kjøre en Debian (eller en av dens derivater), kan systemet bli initialisert med debootstrap, som beskrevet ovenfor. Men hvis den virtuelle maskinen skal monteres med et RPM-basert system (som Fedora, CentOS eller Scientific Linux), vil oppsettet måtte gjøres med yum-verktøyet (tilgjengelig i pakken med samme navn).
Prosedyren krever bruk av rpm for å pakke ut et innledende sett med filer, medregnet spesielt yum-oppsettfiler, og så påkalle yum for å pakke opp de gjenværende pakkesettene. Men siden vi kaller yum fra utsiden av chrooten, trenger vi å gjøre noen midlertidige endringer. I eksemplet nedenfor, er mål-chrooten /srv/centos.
# rootdir="/srv/centos"
# mkdir -p "$rootdir" /etc/rpm
# echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath
# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm
# rpm --nodeps --root "$rootdir" -i centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm
rpm: RPM should not be used directly install RPM packages, use Alien instead!
rpm: However assuming you know what you are doing...
warning: centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
# sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo
# yum --assumeyes --installroot $rootdir groupinstall core
[...]
# sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo