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.
→ https://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 øyeblikksavtrykk av en kjørende virtuell maskin.
→ https://vmware.com/
VirtualBox er en virtuell maskin som for det meste er fri programvare (noen ekstra komponenter er tilgjengelige under en proprietær lisens). Dessverre befinner det i Debians "contrib"-del fordi den inneholder noen forhåndskompilerte filer som ikke kan gjenoppbygges uten en proprietær kompilator, og for tiden finnes den kun i Debian Unstable da Oracles regler gjør det umulig å holde den sikker i Debians stabile utgave (se #794466). Selv om den er yngre enn VMWare og begrenset til i386 og amd64 arkitekturer, inneholder den øyeblikksavtrykk og andre interessante funksjoner.
→ https://www.virtualbox.org/

HARDWARE Virtualiseringsstøtte

Noen datamaskiner har kanskje ikke støtte for maskinvarevirtualisering. når det skjer, bør den aktiveres i BIOS.

Hvis du vil vite om du har aktivert virtualiseringsstøtte, kan du kontrollere om det relevante flagget er aktivert med grep. Hvis følgende kommando for prosessoren returnerer tekst, har du allerede virtualiseringsstøtte aktivert:

For Intel-prosessorer kan du kjøre grep vmx /proc/cpuinfo for å ta rede på om Intel sine utvidelser for virtuelle maskiner støttes.
For Intel-prosessorer kan du kjøre grep vmx /proc/cpuinfo for å ta rede på om AMD sin «Secure Virtual Machine» støttes.

Hvis det er ikke tilfelle kan du gå inn i BIOS på ditt system og lete etter oppføringer som «Intel Virtualization Technology»/«Intel VT-x» eller «SVM mode» (AMD) — vanligvis er disse å finne i prosessor-oppsett i den avanserte delen.

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.

→ https://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:

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

→ https://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 som tilbyr xen-hypervisor være enten xen-hypervisor-4.14-amd64, xen-hypervisor-4.14-armhf, eller xen-hypervisor-4.14-arm64.
En kjerne som kjører på den aktuelle hypervisoren. Enhver kjerne nyere enn 3.0 vil gjøre det, inkludert 5.10 versjon i Bullseye.
i386-arkitekturen krever også et standard bibliotek med de riktige oppdateringer som drar nytte av Xen; dette er i libc6-xen-pakken.

Hypervisoren har også med xen-utils-4.14, 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 sin oppstartsmeny, slik som å starte den valgte kjernen i en Xen Dom0. Merk imidlertid at denne inngangen vanligvis ikke er satt som den første på listen, men er forvalgt.

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-cmd, for å spesifisere hvilken debootstrap-kommando som brukes. Standarden er debootstrap hvis debootstrap og cdebootstrap er installert. I så fall vil alternativet -dist også oftest brukes (med et distribusjonsnavn som bullseye).
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=bullseye --role=udev

General Information
--------------------
Hostname       :  testxen
Distribution   :  bullseye
Mirror         :  http://deb.debian.org/debian
Partitions     :  swap            512M  (swap)
                  /               2G    (ext4)
Image type     :  sparse
Memory size    :  256M
Bootloader     :  pygrub

[...]
Logfile produced at:
	 /var/log/xen-tools/testxen.log

Installation Summary
---------------------
Hostname        :  testxen
Distribution    :  bullseye
MAC Address     :  00:16:3E:C2:07:EE
IP Address(es)  :  dynamic
SSH Fingerprint :  SHA256:K+0QjpGzZOacLZ3jX4gBwp0mCESt5ceN5HCJZSKWS1A (DSA)
SSH Fingerprint :  SHA256:9PnovvGRuTw6dUcEVzzPKTITO0+3Ki1Gs7wu4ke+4co (ECDSA)
SSH Fingerprint :  SHA256:X5z84raKBajUkWBQA6MVuanV1OcV2YIeD0NoCLLo90k (ED25519)
SSH Fingerprint :  SHA256:VXu6l4tsrCoRsXOqAwvgt57sMRj2qArEbOzHeydvV34 (RSA)
Root Password   :  FS7CUxsY3xkusv7EkbT9yae

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 hvordan 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-pakken anbefaler den) for å erstatte den eksisterende eth0-oppføringen (vær nøye på at du bruker rett navn på nettverksenheten):

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. Du må kanskje øke standardminnet ved å redigere variabelminnet fra oppsettfilen (i dette tilfellet /etc/xen/testxen.cfg). Her har vi satt den til 1024 (megabyte).

# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  3918     2     r-----      35.1
# 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  2757     2     r-----      45.2
testxen                                      3  1024     1     r-----       1.3

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-konsollen, med xl console-kommandoen:

# xl console testxen
[...]

Debian GNU/Linux 11 testxen hvc0

testxen-innlogging:

Man kan så åpne en økt, 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 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.

De fleste av xl-underkommandoer forventer ett eller flere argumenter, ofte et DomU-navn. Disse argumentene er godt beskrevet på manualsiden xl(1).

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.

→ https://xenproject.org/help/documentation/

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 «kontainer» (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; kontaineren 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 kontainer (enten en annen Linux-versjon, eller et annet operativsystem i det hele tatt).

MERK LXC isolasjonsgrenser

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

ettersom kjernen er delt mellom vertssystemet og kontainere, kan prosesser avgrenset til kontainere fortsatt få tilgang til kjernemeldinger, noe som kan føre til informasjonslekkasje hvis meldingene er sendt ut fra en kontainer;
av lignende grunner, hvis en kontainer er kompromittert og et sikkerhetsproblem i kjernen utnyttes, kan de øvrige kontainerne 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 kontainer, noe en bør huske på om skrivbare deler av filsystemet er delt mellom kontainere.

Siden vi har å gjøre med isolering, og ikke vanlig virtualisering, er det å sette opp LXC-kontainere 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 kontainer.

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 kunne holde dem isolert fra nettverket, og bare kommunisere med dem via filsystemet, innebærer de fleste brukstilfeller i det minste å gi minimal nettverkstilgang til kontainerne. I det typiske tilfellet vil hver kontainer få et virtuelt nettverksgrensesnitt koblet til det virkelige nettverket via en bro. Dette virtuelle grensesnittet kan kobles enten direkte på vertens fysiske nettverksgrensesnitt (der kontaineren 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 eller enp1s0) 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 br0
iface br0 inet dhcp
    bridge-ports eth0

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

I tilfeller der dette oppsettet ikke kan brukes (for eksempel, hvis ingen offentlige IP-adresser kan tildeles kontainere), blir et virtuelt tap-grensesnitt opprettet og koblet til broen. Den tilsvarende nettverkstopologien blir da som en vert med et ekstra nettverkskort koblet til en egen svitsj, med kontainere koblet til den samme svitsjen. Verten fungerer da som en inngangsport for kontainere hvis de er ment å kommunisere med omverdenen.

I tillegg til bridge-utils, krever dette «rike» oppsettet vde2-pakken; /etc/network/interfaces-filen blir da:

# Grensesnittet eth0 er ikke endret
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 kontainere, eller dynamisk med en DHCP-tjener som kjører hos verten. En slik DHCP-tjener må settes opp til å svare på forespørsler på br0-grensesnittet.

12.2.2.3. Oppsett av systemet

La oss nå sette opp filsystemet som skal brukes av kontaineren. Siden denne «virtuelle maskinen» ikke vil kjøres direkte på maskinvare, er noen finjusteringer nødvendige sammenlignet med et standard-filsystem, særlig når det gjelder kjernen, enheter og konsollene. Heldigvis inkluderer lxc-pakken skript som stort sett automatiserer dette oppsettet. For eksempel vil følgende kommandoer (som krever debootstrap og rsync-packages) installere en Debiankontainer:

# lxc-create -n testlxc -t debian
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... 
Downloading debian minimal ...
I: Retrieving Release 
I: Retrieving Release.gpg 
[...]
Download complete.
Copying rootfs to /var/lib/lxc/testlxc/rootfs...
[...]
#

Merk at filsystemet opprinnelig er opprettet i /var/cache/lxc, og deretter flyttet til den katalogen filsystemet skal ende opp. Dette gjør det mulig å lage identiske kontainere 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.

Pakken lxc lager så et bro-grensesnitt som heter lxcbr0. Som forvalg brukes dette av alle nyopprettede kontainere via /etc/lxc/default.conf og lxc-net-tjenesten:

lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up

Disse oppføringene betyr, henholdsvis, at et virtuelt grensesnitt vil bli opprettet hver ny kontainer; at det automatisk vil være aktivt når det blir meldt at kontaineren er startet; samt at det automatisk vil bli koblet til lxcbr0-broen hos verten. Du vil finne disse innstillingene i den opprettede kontainerens oppsett (/var/lib/lxc/testlxc/config), der også enhetens MAC-adresse vil være spesifisert i lxc.net.0.hwaddr. Skulle denne siste posten mangle eller være deaktivert, vil det genereres en tilfeldig MAC-adresse.

En annen nyttig oppføring i den filen er innstillingen for vertsnavnet:

lxc.uts.name = testlxc

Det nyopprettede filsystemet inneholder nå et minimalt Debian-system og et nettverksgrensesnitt.

12.2.2.4. Oppstart av kontainer

Nå som vårt virtuelle maskinbilde er klart, la oss starte kontaineren: med lxc-start --name=testlxc.

I LXC-versjoner som fulgte 2.0.8 angis ikke rot-passord som forvalg. Vi kan sette et som kjører lxc-attach -n testlxc passwd hvis vi ønsker det. Nå kan vi logge inn:

# lxc-console -n testlxc
Connected to tty 1
Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself

Debian GNU/Linux 11 testlxc tty1

testlxc login: root
Password: 
Linux testlxc 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) 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.
Last login: Wed Mar  9 01:45:21 UTC 2022 on console
root@testlxc:~# ps auxwf
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.2  18964 11464 ?        Ss   01:36   0:00 /sbin/init
root          45  0.0  0.2  31940 10396 ?        Ss   01:37   0:00 /lib/systemd/systemd-journald
root          71  0.0  0.1  99800  5724 ?        Ssl  01:37   0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid [..]
root          97  0.0  0.1  13276  6980 ?        Ss   01:37   0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root         160  0.0  0.0   6276  3928 pts/0    Ss   01:46   0:00 /bin/login -p --
root         169  0.0  0.0   7100  3824 pts/0    S    01:51   0:00  \_ -bash
root         172  0.0  0.0   9672  3348 pts/0    R+   01:51   0:00      \_ ps auxwf
root         164  0.0  0.0   5416  2128 pts/1    Ss+  01:49   0:00 /sbin/agetty -o -p -- \u --noclear [...]
root@testlxc:~#

Nå er vi i kontaineren; vår tilgang til prosessene er begrenset til bare dem som er startet fra kontaineren selv, og vår tilgang til filsystemet er tilsvarende begrenset til den øremerkede delmengden av hele filsystemet (/var/lib/lxc/testlxc/rootfs). Vi kan gå ut av konsollen med Control+a q.

Legg merke til at vi kjørte kontaineren som en bakgrunnsprosess, takket være at lxc-start har begynt å forvelge --daemon-argumentet. Vi kan avbryte kontaineren med en kommando som for eksempel lxc-stop --name=testlxc.

Pakken lxc inneholder et initialiseringsskript som automatisk kan starte en eller flere kontainere når verten starter opp (det er avhengig av lxc-autostart som starter kontainere 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 kontainere som er en del av onboot-gruppen, og deretter kontainere 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 kontainere. Dette vil vanligvis oppnås med lxc.mount.entry-innganger i kontainernes oppsettfil. En interessant bieffekt er at prosessene da vil bruke mindre fysisk minne, siden kjernen er i stand til å oppdage felles programmer. Den marginale kostnaden for en ekstra kontainer kan da reduseres til diskplassen øremerket til dens spesifikke data, og noen ekstra prosesser som kjernen må håndtere og planlegge når skal kjøre.

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. Den virtuelle qemu-kvm-pakken gir kun 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). virt-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 libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system gir bakgrunnsprosessen libvirtd, som tillater (potensielt ekstern) håndtering av virtuelle maskiner som kjører på verten, og starter de nødvendige VM-er når vertsmaskinen starter opp. libvirt-clients gir virsh-kommandolinjeverktøyet 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 forvalgt plassering (/var/lib/libvirt/images/) gjør nytten.

# mkdir /srv/kvm
# virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created

#

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            
               --memory 2048             
               --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10  
               --cdrom /srv/isos/debian-11.2.0-amd64-netinst.iso  
               --network bridge=virbr0   
               --graphics vnc            
               --os-type linux           
               --os-variant debiantesting


Starter intallasjon …
Tildeler 'testkvm.qcow'

	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 `--memory` 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 (`qcow2`) tillater [ starte 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). Forvalgt nettverksoppsett som inneholder definisjonen for et `virbr0`-brogrensesnitt, og kan redigeres ved bruk av `virsh net-edit default` og startes via `virsh net-start default` hvis det ikke allerede gjøres automatisk under oppstart av systemet.
	`--graphics 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.4, «Å lage krypterte tunneler med portvideresending (Port Forwarding)»). Alternativt kan `--graphics vnc,listen=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. Full liste over OS-typer kan vises ved bruk av `osinfo-query os`-kommandoen fra libosinfo-bin-pakken.

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@tjener/system testkvm
root@tjenerens passord: 
root@tjenerens passord:

Figur 12.1. Tilkobling til installasjonsprogrammet ved bruk av virt-viewer

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
----------------------------------
  8 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
127.0.0.1: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.

Installasjon av RPM-basert chroot i Debian med YUM

Hvis chroot er ment å kjøre Debian (eller avledet fra Debian), kan systemet bli igangsettes med debootstrap. Hvis det må installeres med et RPM-basert system (som for eksempel Fedora, CentOS, eller Scientific Linux), vil oppsettet måtte gjøres med yum-verktøyet, tilgjengelig som yum4 i nextgen-yum4-pakken, siden det opprinnelige programmet har blitt fjernet fra Debian i forkant av utgivelsen av Bullseye fordi det ikke ble vedlikeholdt, var utdatert, og foreldet i favør av dnf.

Prosedyren krever bruk av rpm for å pakke ut et innledende sett med filer, medregnet spesielt yum-oppsettsfiler, og så påkalle yum4 for å pakke opp de gjenværende pakkesettene. Men siden vi kaller yum4 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-9.2009.0.el7.centos.x86_64.rpm
# rpm --nodeps --root "$rootdir" -i centos-release-7-9.2009.0.el7.centos.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-9.2009.0.el7.centos.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
# yum4 --assumeyes --installroot $rootdir groupinstall core
[...]
# sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo
# chroot /srv/centos/
[root@testsystem /]#