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 tjenermaskin kan så være vert for flere systemer som arbeider samtidig, og i isolasjon. Bruksområdene er mange, og utledes ofte fra denne isolasjonen: for eksempel testmiljøer med varierende oppsett, 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 implementasjoner verdt å nevne er de følgende:

QEMU er en programvare-emulator for en komplett datamaskin. Ytelsen er langt fra den hastigheten man kunne oppnå ved å kjøre direkte på maskinvaren, men den tillater å kjøre uendrede eller eksperimentelle operativsystemer på den emulerte maskinvaren. Den tillater også å emulere en annen maskinvarearkitektur: For eksempel, kan et amd64-system emulere en arm-datamaskin. QEMU er fri programvare.
→ http://www.qemu.org/
Bochs er en annen fritt tilgjengelig virtuell maskin, men den emulerer bare x86-arkitekturene (i386 og amd64).
VMWare er en proprietær virtuell maskin; og som en av de eldste der ute, er den også en av de mest kjente. Den fungerer på prinsipper som ligner på QEMU. VMWare tilbyr avanserte funksjoner som å ta øyeblikksbilder av en kjørende virtuell maskin.
→ http://www.vmware.com/
VirtualBox is a virtual machine that is mostly free software (some extra components are available under a proprietary license). Unfortunately it is in Debian's “contrib” section because it includes some precompiled files that cannot be rebuilt without a proprietary compiler and it currently only resides in Debian Unstable as Oracle's policies make it impossible to keep it secure in a Debian stable release (see #794466). While younger than VMWare and restricted to the i386 and amd64 architectures, it still includes some snapshotting and other interesting features.
→ http://www.virtualbox.org/

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 for 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 ytelsen ikke blir dårligere, og systemer kjører med nær sin normale 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å terminologi. Hypervisoren er det nederste laget, som kjører direkte på maskinvaren, under kjernen. Denne hypervisoren kan dele resten av programvaren over flere domener, som kan sees på som like mange virtuelle maskiner. Et 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 kalles domU. Med andre ord, og fra et brukersynspunkt, tilsvarer dom0 «verten» i andre visualiseringssystemer, mens en domU kan bli sett på som en «gjest».

KULTUR Xen og de ulike versjonene av Linux

Xen ble opprinnelig utviklet som et sett endringer som eksisterte på utsiden av det offisielle treet, og som ikke ble integrert i Linux-kjernen. Samtidig krevde flere fremvoksende virtualiseringssystemer (inkludert KVM) noen generiske virtualiseringsrelaterte funksjoner for å lette integreringen sin, og Linux-kjernen fikk dette settet av funksjoner (kjent som paravirt_ops, eller pv_ops-grensesnittet). Ettersom Xen dupliserte noen av funksjonalitetene til dette grensesnittet, kunne de ikke bli offisielt akseptert.

XenSource, selskapet bak Xen, måtte derfor legge til Xen i dette nye rammeverket, slik at Xens rettelser kunne flettes inn i den offisielle Linux-kjernen. Det betydde mye omskriving av kode, og selv om XenSource snart hadde en fungerende versjon basert på paravirt_ops-grensesnittet, ble rettelsene bare gradvis fusjonert inn den offisielle kjernen. Flettingen ble ferdigstilt i Linux 3.0.

→ http://wiki.xenproject.org/wiki/XenParavirtOps

Ettersom Jessie er basert på Linux-kjernens versjon 3.16, inkluderer standardpakkene linux-image-686-pae, og linux-image-amd64 den nødvendige koden, og distribusjonsspesifikke endringer som trengs til Squeeze, og tidligere versjoner av Debian trengs ikke lenger.

→ http://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

KULTUR Xen og ikke-Linux kjerner

Xen krever endringer i alle operativsystemer man ønsker å kjøre på den. Alle kjerner har ikke samme modenhetsnivå når det gjelder dette. Mange er fullt funksjonelle, både som Dom0 og DomU: Linux 3.0 og senere, NetBSD 4.0 og senere, og OpenSolaris. Andre funger bare som en DomU. Du kan sjekke status for hvert operativsystem i Xen-Wikien:

→ http://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ http://wiki.xenproject.org/wiki/DomU_Support_for_Xen

Men hvis Xen kan stole på maskinvarefunksjonene øremerket til virtualisering (som bare er til stede i nyere prosessorer), kan til og med ikke-modifiserte operativsystemer kjøres som DomU (inkludert Windows).

Å bruke Xen under Debian krever tre komponenter:

Selve hypervisoren. Alt 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å oppsettskriptene 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ødvendighetene er installert, er neste skritt å teste hvordan Dom0 virker alene. 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.

Så er det 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 oppsettsfilen /etc/xen-tools/xen-tools.conf, 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 diskene» 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).
FOR VIDEREKOMMENDE Installasjon av ikke-Debian-system i DomU
Med et ikke-Linux-system må en, ved hjelp av --kernel-valget, passe på å definere kjernen DomU må bruke.
--dhcp sier at DomUs nettverksoppsett skal hentes med DHCP, mens --ip lar en 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.
MERK Lagring i domU
Hele harddisker kan også bli eksportert til DomU, samt partisjoner, RAID-sett, eller eksisterende logiske data fra tidligere. Disse operasjonene blir imidlertid ikke automatisert av xen-create-image, så å redigere Xen-bildets oppsettsfil er greit etter det første oppsettet med xen-create-image.

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

Nå har vi 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 på disse virtuelle maskinene, må vi definere en skal få tilgang til dem. De kan selvfølgelig sees som isolerte maskiner, som bare nås gjennom sine systemkonsoller. Men dette stemmer 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 innbefatter en rekke grensesnitt med uvanlige navn, for eksempel vif*, veth*, peth* og xenbr0. Xen-hypervisoren setter dem opp med det utlegget som har blitt definert og kontrollert av verktøy i brukerland. Siden NAT- og rutingmodellene bare er tilpasset det enkelte tilfelle, vil vi bare omtale bridge-modellen.

Standardoppsettet for Xen-pakkene endrer ikke hele systemets nettverksoppsett. Men bakgrunnsprosessen xend er satt opp for å integrere inn virtuelle nettverksgrensesnitt i alle nettverksbroer som eksisterer fra før (der xenbr0 tar forrang dersom flere slike broer finnes). Vi må derfor sette opp en bro i /etc/network/interfaces (som krever installasjon av pakken bridge-utils, 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 å ha startet maskinen på nytt 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

VÆR VARSOM Bare ett DomU per bilde!

Mens det selvfølgelig er mulig å ha flere DomU-systemer som kjører parallelt, har alle behov for å bruke sitt eget bilde, siden hvert DomU er laget for å tro det kjører på sin egen maskinvare (bortsett fra den lille biten av kjernen som snakker til hypervisor). Spesielt er det ikke mulig for to DomU-systemer, som kjører samtidig, å dele lagringsplass. Hvis DomU-systemene ikke kjører samtidig, er det imidlertid fullt mulig å gjenbruke en enkel vekselminnepartisjon, eller partisjonen som er vert for filsystemet /home.

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 et DNS-oppsett. Den andre måten, som kan være den eneste måten hvis nettverksoppsettet 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 økt, akkurat som man ville gjøre hvis du sitter med den virtuelle maskinens tastatur. Frakobling fra dette konsollet oppnås med Control+]-tastekombinasjon.

Når DomU kjører, kan den brukes akkurat som en hvilken som helst annen tjenermaskin (siden den tross alt er et GNU/Linux-system). Imidlertid tillater den virtuelle maskinstatusen noen ekstra funksjoner. For eksempel kan en DomU midlertidig stoppes, og så begynne igjen, med kommandoene xl pause, og xl unpause. Merk at selv om DomU i pause ikke bruker noen prosessorkraft, er det tildelte minnet fortsatt i bruk. Det kan være interessant å vurdere kommandoene xl save og xl restore: Å lagre en DomU frigjør ressursene som tidligere ble brukte, inkludert RAM. Når den hentes inn igjen (eller pausen avsluttes, 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 gjenoppretter den ved neste oppstart. Dette vil selvfølgelig medføre at de vanlige ubekvemmelighetene som oppstår når en bærbar datamaskin settes i dvalemodus. For eksempel, spesielt hvis DomU er suspendert for lenge, kan nettverkstilkoblinger gå ut på tid. Merk også at Xen så langt er uforenlig med en stor del av ACPI-strømstyringen, noe som utelukker suspensjon av Dom0-vertsystemet.

Stopping og omstart av en DomU kan gjøres enten fra DomU-et (med shutdown command) eller fra Dom0, med xl shutdown, eller xl reboot.

FOR VIDEREKOMMENDE Avansert Xen

Xen har mange flere funksjoner enn vi kan beskrive i et par avsnitt. Spesielt er systemet meget dynamisk, og mange parametere for et domene (for eksempel mengden tildelt minne, synlige harddisker, oppførselen til oppgaveplanleggeren, og så videre) kan justeres selv når domenet er i gang. Et DomU kan også overføres på tvers av tjenermaskiner uten å bli slått av, og uten å miste sine nettverkstilkoblinger! For alle disse avanserte mulighetene er primærkilden til informasjon den offisielle Xen-dokumentasjonen.

→ http://www.xen.org/support/documentation.html

12.2.2. LXC

Selv om LXC brukes til å bygge «virtuelle maskiner», er det strengt tatt ikke et virtualiseringssystem, men et system for å isolere grupper av prosesser fra hverandre, selv om de alle kjører på den samme vertsmaskin. Det trekker veksler på et sett av nyutviklinger i Linux-kjernen, kjent som kontrollgrupper, der forskjellige sett med prosesser som kalles «grupper» har ulikt utsyn til forskjellige aspekter ved det totale systemet. Mest kjent blant disse aspektene er prosessidentifikatorene, nettverksoppsettene 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 satt opp til å bare se et delsett av de tilgjengelige verktøy som finnes i systemet.

Disse egenskapene 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 ekstra kjerne; 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).

MERK LXC isolasjonsgrenser

LXC beholdere gir ikke det isolasjonsnivået som oppnås med tyngre emulatorer eller virutaliseringer. Spesielt:

ettersom kjernen er delt mellom vertssystemet og beholderne, kan prosesser avgrenset til beholdere fortsatt få tilgang til kjernemeldinger, noe som kan føre til informasjonslekkasje hvis meldingene er sendt ut fra en beholder;
av lignende grunner, hvis en beholder er kompromittert og et sikkerhetsproblem i kjernen utnyttes, kan de øvrige beholdere også bli påvirket;
på filsystemet sjekker kjernen rettigheter ved hjelp av de numeriske identifikatorer for brukere og grupper. Disse identifikatorene kan henvise til forskjellige brukere og grupper avhengig av beholderen, noe en bør huske på om skrivbare deler av filsystemet er delt mellom beholdere.

Siden vi har å gjøre med isolasjon, og ikke vanlig virtualisering, er å sette opp LXC-beholdere mer komplisert enn bare å kjøre debian-installer på en virtuell maskin. Vi vil beskrive noen forutsetninger, og går deretter videre til nettverksoppsettet. Da vil vi faktisk være i stand til å lage systemet som skal kjøres i beholderen.

12.2.2.1. Innledende steg

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 oppsett.

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 tilfeller kreves pakken bridge-utils.

Det enkle tilfellet trenger kun endring i /etc/network/interfaces, for å flytte oppsettet for det fysiske grensesnittet (for eksempel eth0) til et brogrensesnitt (vanligvis br0), og sette opp koblingen mellom dem. For eksempel, hvis nettverksoppsettsfilen i utgangspunktet inneholder oppføringer som de følgende:

auto eth0
iface eth0 inet dhcp

De bør deaktiveres og erstattes med følgende:

#auto eth0
#iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
  bridge-ports eth0

Effekten av dette oppsettet vil ligne på hva som ville blitt oppnådd dersom beholderne var maskiner koblet til det samme fysiske nettverket som vert. Bro-oppsettet (“bridge”-oppsettet) håndterer transitt av Ethernet-rammer mellom alle bro-grensesnitt som inkluderer fysisk eth0, samt grensesnittet definert for beholderne.

I tilfeller der dette oppsettet 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 dette «rike» oppsettet vde2-pakken; /etc/network/interfaces-filen blir da:

# Grensesnitt eth0 er uendret
auto eth0
iface eth0 inet dhcp

# Virtuelt grensesnitt
auto tap0
iface tap0 inet manual
  vde2-switch -t tap0

# Bru for kontainere
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å settes opp til å svare på spørsmål om br0-grensesnittet.

12.2.2.3. Oppsett av 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 dette oppsettet. 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 oppsettsfil (/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 konsollen 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.

FOR VIDEREKOMMENDE Massevirtualisering

Siden LXC er et meget lett isolasjonssystem, kan det spesielt tilpasses til å være et massivt vertskap for virtuelle tjenere. Nettverksoppsettet vil trolig være litt mer avansert enn hva vi beskrev ovenfor, men det «rike» oppsettet som bruker tap og veth-grensesnitt skulle i mange tilfelle være nok.

Det kan også være fornuftig å ha en del av filsystemet felles, slik som /usr og /lib-undertrærne, slik at man unngår å duplisere programvaren som kanskje må være felles for flere containere. Dette vil vanligvis oppnås med lxc.mount.entry-innganger i beholdernes oppsettfil. En interessant bieffekt er at prosessene da vil bruke mindre fysisk minne, siden kjernen er i stand til å oppdage felles programmer. Den marginale belastningen for en ekstra beholder kan da reduseres til diskplassen øremerket til dens spesifikke data, og noen ekstra prosesser som kjernen må planlegge, og administrere.

Vi har selvfølgelig ikke beskrevet alle de tilgjengelige alternativene. Mer omfattende informasjon kan fås fra lxc(7) og lxc.container.conf(5)-manualsider og sidene de refererer til.

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 steg

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-bakgrunnsprosessen, 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 det hyppigste nettverksoppsettet en bro som grupperer nettverksgrensesnittene og de virtuelle maskinene (se Seksjon 12.2.2.2, «Nettverksoppsett»).

Alternativt, og i standardoppsettet, 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 vertssystemet. 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  
               --virt-type kvm           
               --name testkvm            
               --ram 1024                
               --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10 
               --cdrom /srv/isos/debian-8.1.0-amd64-netinst.iso  
               --network bridge=br0      
               --vnc                     
               --os-type linux           
               --os-variant debianwheezy

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

	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`).
	Siden KVM forvaltes på samme måte som QEMU, tillater `--virt-type kvm` å spesifisere bruken av KVM selv om nettadressen ser ut som QEMU.
	Valget V`--name` definerer et (unikt) navn for den virtuelle maskinen.
	Valget `--ram` kan spesifisere hvor mye RAM (i MB) som skal avsettes til den virtuelle maskinen.
	`--disk` angir plasseringen av bildefilen som skal representere harddisken til vår virtuelle maskin; 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.
	`--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`).
	`--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).
	`--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 .
	`--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 virtuelle maskinen:

# virsh -c qemu:///system start testkvm
Domain testkvm started

Vi kan nå få tilkoblingsinstruksjonene til den grafiske konsollen (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-oppsettsfiler, 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