Product SiteDocumentation Site

12.2. Virtualització

La virtualització és un dels avenços més importants en els últims anys de la informàtica. El terme cobreix diverses abstraccions i tècniques per simular ordinadors virtuals amb un grau variable d'independència respecte el maquinari real. Un servidor físic pot albergar diversos sistemes que treballen al mateix temps i de forma aïllada. Les aplicacions són moltes, i sovint deriven d'aquest aïllament: entorns de prova amb configuracions diferents, per exemple, o separació de serveis allotjats a través de diferents màquines virtuals per seguretat.
Hi ha múltiples solucions de virtualització, cadascuna amb els seus propis avantatges i inconvenients. Aquest llibre se centrarà en Xen, LXC i KVM, però altres implementacions notables inclouen:

12.2.1. Xen

Xen és una solució de “paravirtualització”. Presenta una capa d'abstracció prima, anomenada “hipervisor”, entre el maquinari i els sistemes superiors; això actua com un àrbitre que controla l'accés al maquinari de les màquines virtuals. Tanmateix, només gestiona algunes de les instruccions, la resta és directament executada pel maquinari en nom del sistema. L'avantatge principal és que el rendiment no queda degradat, i els sistemes s'executen gairebé la velocitat nativa; l'inconvenient és que els nuclis dels sistemes operatius que es volen utilitzar en un hipervisor de Xen s'han d'adaptar per treballar amb Xen.
Passem una mica de temps amb els termes. L'hipervisor és la capa inferior, que funciona directament en el maquinari, fins i tot per sota del nucli. Aquest hipervisor pot dividir la resta del programari en diversos dominis, que es poden veure com a tantes màquines virtuals. Un d'aquests dominis (el primer que comença) és conegut com dom0, i té un paper especial, ja que només aquest domini pot controlar l'hipervisor i l'execució d'altres dominis. Aquests altres dominis es coneixen com domU. En altres paraules, i des del punt de vista de l'usuari, el dom0 coincideix amb l'“amfitrió” d'altres sistemes de virtualització, mentre que un domU pot ser vist com un “convidat”.
L'ús de Xen amb Debian requereix tres components:
  • L'hipervisor mateix. D'acord amb el maquinari disponible, el paquet apropiat proveint xen-hypervisor serà xen-hipervisor-4.14-amd64, xen-hipervisor-4.14-armhf, o xen-hipervisor-4.14-arm64.
  • Un nucli que s'executi sobre aquest hipervisor. Qualsevol nucli més recent que el 3.0 ho farà, incloent-hi la versió 5.10 present a Bullseye.
  • L'arquitectura i386 també requereix una biblioteca estàndard amb els pedaços apropiats que aprofiten Xen; això es troba al paquet libc6-xen.
L'hipervisor també porta xen-utils-4.14, que conté eines per controlar l'hipervisor des de la dom0. Això, al seu torn, porta la biblioteca estàndard apropiada. Durant la instal·lació de tot això, els scripts de configuració també creen una nova entrada al menú d'arrencada de GRUB, per tal d'iniciar el nucli escollit en un Xen dom0. No obstant això, cal tenir en compte que aquesta entrada no sol ser la primera de la llista, però serà seleccionada per defecte.
Una vegada instal·lats aquests requisits previs, el següent pas és provar el comportament del dom0 per si mateix; això implica un reinici cap a l'hipervisor i el nucli Xen. El sistema hauria d'arrencar en la seva forma estàndard, amb alguns missatges addicionals a la consola durant els primers passos d'inicialització.
Ara és el moment d'instal·lar sistemes útils en els sistemes domU, utilitzant les eines de xen-tools. Aquest paquet proporciona l'ordre xen-create-image, que en gran part automatitza la tasca. L'únic paràmetre obligatori és --hostname, que dóna un nom a la domU; altres opcions són importants, però es poden desar al fitxer de configuració /etc/xen-tools/xen-tools.conf, i la seva absència a la línia d'ordres no activa cap error. Per tant, és important comprovar el contingut d'aquest fitxer abans de crear imatges, o utilitzar paràmetres addicionals en la invocació de xen-create-image. Els paràmetres importants a tenir en compte inclouen:
  • --memory, per especificar la quantitat de RAM dedicada al sistema acabat de crear;
  • --size i --swap, per definir la mida dels "discos virtuals" disponibles per al domU;
  • --debootstrap-cmd, per especificar quina ordre de debootstrap s'utilitza. El valor per defecte és debootstrap si debootstrap i cdebootstrap estan instal·lats. En aquest cas, l'opció --dist també s'utilitzarà més sovint (amb un nom de distribució com ara bullseye).
  • --dhcp indica que la configuració de la xarxa de domU s'ha d'obtenir mitjançant DHCP, mentre que --ip permet definir una adreça IP estàtica.
  • Finalment, s'ha de triar un mètode d'emmagatzematge per a les imatges que es crearan (aquelles que es veuran com a discos durs des de la domU). El mètode més simple, que correspon a l'opció --dir, és crear un fitxer al dom0 per a cada dispositiu que s'ha de proporcionar al domU. Per a sistemes que utilitzen LVM, l'alternativa és utilitzar l'opció --lvm, seguida pel nom d'un grup de volums; xen-create-image crearà un nou volum lògic dins d'aquest grup, i aquest volum lògic estarà disponible a la domU com a disc dur.
Una vegada que es prenen aquestes decisions, podem crear la imatge per al nostre futur domU de Xen:
# 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
Ara tenim una màquina virtual, però actualment no s'està executant (i, per tant, només utilitza espai al disc dur del dom0). Per descomptat, podem crear més imatges, possiblement amb paràmetres diferents.
Abans d'engegar aquestes màquines virtuals, hem de definir com s'accediran. Per descomptat, es poden considerar màquines aïllades, només accessibles a través de la seva consola de sistema, però això rarament coincideix amb el patró d'ús. La major part del temps, un domU es considerarà un servidor remot, i només s'accedirà a través d'una xarxa. No obstant això, seria bastant incòmode afegir una targeta de xarxa per a cada domU; per això Xen permet crear interfícies virtuals que cada domini pot veure i utilitzar de manera habitual. Tingueu en compte que aquestes targetes, encara que siguin virtuals, només seran útils una vegada connectades a una xarxa, fins i tot una de virtual. Xen té diversos models de xarxa per a això:
  • El model més simple és el model bridge; totes les targetes de xarxa eth0 (tant al dom0 com als sistemes domU) es comporten com si estiguessin connectades directament a un commutador Ethernet.
  • Després ve el model d'encaminament, on el dom0 es comporta com un encaminador que es troba entre els sistemes domU i la xarxa externa (física).
  • Finalment, en el model NAT, el dom0 es troba de nou entre els sistemes domU i la resta de la xarxa, però els sistemes domU no són directament accessibles des de l'exterior, i el trànsit passa a través d'una traducció d'adreces de xarxa a la dom0.
Aquests tres nodes de xarxa impliquen una sèrie d'interfícies amb noms inusuals, com vif*, veth*, peth* i xenbr0. L'hipervisor Xen disposa en qualsevol disposició que s'hagi definit, sota el control de les eines d'espai d'usuari. Com que els models NAT i d'encaminament només estan adaptats a casos particulars, només ens ocuparem del model de pont («bridging»).
La configuració estàndard dels paquets Xen no canvia la configuració de xarxa del sistema. No obstant això, el dimoni xend està configurat per integrar les interfícies de xarxa virtuals en qualsevol pont de xarxa preexistent (amb xenbr0 tenint precedència si existeixen diversos d'aquests ponts). Per tant, hem d'establir un pont a /etc/network/interfaces (que requereix la instal·lació del paquet bridge-utils, que és el motiu pel qual el paquet xen-utils-4.14 el recomana) per reemplaçar l'entrada eth0 existent (però sigueu curosos d'usar el nom del dispositiu de xarxa correcte:
auto xenbr0
iface xenbr0 inet dhcp
    bridge_ports eth0
    bridge_maxwait 0
Després de reiniciar per assegurar-se que el pont es crea automàticament, ara podem iniciar el domU amb les eines de control Xen, en particular l'ordre xl. Aquesta ordre permet diferents manipulacions als dominis, incloent-hi llistar-los i iniciar/aturar-los. És possible incrementar la memòria per defecte editant la variable memòria del fitxer de configuració (en aquest cas, /etc/xen/testxen.cfg). Aquí l'hem establert a 1024 (megabytes).
# 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
Tingueu en compte que el domU testxen utilitza memòria real, no simulada, presa de la RAM que d'altra manera estaria disponible per a la memòria dom0. Per tant, s'hauria de tenir cura quan es munti un servidor destinat a albergar instàncies Xen de proveir la RAM física en conseqüència.
Voilà! La nostra màquina virtual està iniciant-se. Podem accedir-hi de dues maneres. La forma habitual és connectar-s'hi “remotament” a través de la xarxa, ja que ens connectaríem a una màquina real; això sol requerir la creació d'un servidor DHCP o alguna configuració DNS. L'altra manera, que pot ser l'única via si la configuració de xarxa és incorrecta, és utilitzar la consola hvc0, amb l'ordre xl console:
# xl console testxen
[...]

Debian GNU/Linux 11 testxen hvc0

testxen login: 
Llavors es pot obrir una sessió, com si s'estigués assegut al teclat de la màquina virtual. Desconnectar-te d'aquesta consola s'aconsegueix a través de la combinació de tecles Control+].
Una vegada que el domU està engegat, es pot utilitzar com qualsevol altre servidor (ja que després de tot és un sistema GNU/Linux). Tanmateix, el seu estat de la màquina virtual permet algunes característiques addicionals. Per exemple, un domU pot ser pausat temporalment i després es pot reprendre amb les ordres xl pause i xl unpause. Tingueu en compte que, tot i que un domU en pausa no utilitza cap cicle de processador, la seva memòria assignada encara està en ús. Pot ser interessant considerar les ordres xl save i xl restore: desar («save») un domU allibera els recursos que anteriorment eren usats per aquest domU, incloent-hi la RAM. Quan es restaura (o es reprèn, que ve a ser el mateix en aquest cas), un domU no se n''adona de res més enllà temps que pugui haver passat. Si un domU s'estava executant quan el dom0 s'atura, els scripts inclosos automàticament desaran el domU, i el reprendran a la següent arrencada. Això implicarà, per descomptat, les molèsties habituals en la hibernació d'un ordinador portàtil, per exemple; en particular, si el domU està suspès durant massa temps, les connexions de xarxa poden expirar. Cal tenir en compte que Xen és fins ara incompatible amb una gran part de la gestió d'energia ACPI, que exclou la possibilitat de suspensió del sistema amfitrió (dom0).
L'aturada o el reinici d'un domU es pot fer des del domU (amb l'ordre shutdown) o des del dom0 amb xl shutdown o xl reboot).
La majoria de les subordres xl esperen un o més arguments, sovint un nom de domU. Aquests arguments estan ben descrits en la pàgina del manual xl(1).

12.2.2. LXC

Tot i que s'utilitza per construir "màquines virtuals", LXC no és, estrictament parlant, un sistema de virtualització, sinó un sistema per aïllar grups de processos entre ells, tot i que tots funcionen en el mateix hoste. Aprofita un conjunt de canvis recents en el nucli de Linux, coneguts col·lectivament com a «control groups» o “grups de control”, mitjançant els quals diferents conjunts de processos anomenats “grups” tenen diferents visions sobre certs aspectes del sistema global. Entre aquests aspectes destaquen els identificadors de procés, la configuració de la xarxa i els punts de muntatge. Aquest grup de processos aïllats no tindrà accés als altres processos del sistema, i els accessos al sistema de fitxers es poden restringir a un subconjunt específic. També pot tenir la seva pròpia interfície de xarxa i taula d'encaminament, i es pot configurar per veure només un subconjunt dels dispositius disponibles presents al sistema.
Aquestes característiques es poden combinar per aïllar tota una família de processos a partir del procés init, i el conjunt resultant s'assembla molt a una màquina virtual. El nom oficial d'aquesta configuració és “contenidor” (d'aquí el sobrenom d'LXC: LinuX Containers), però una diferència bastant important amb les màquines virtuals "reals" com les proporcionades per Xen o KVM és que no hi ha cap segon nucli; el contenidor utilitza el mateix nucli que el sistema host. Això té tant avantatges com incovenients: els avantatges inclouen un rendiment excel·lent a causa de la manca total de sobrecàrrega, i el fet que el nucli té una visió global de tots els processos que s'executen al sistema, de manera que la planificació pot ser més eficient del que seria si dos nuclis independents programessin diferents conjunts de tasques. El principal dels inconvenients és la impossibilitat d'executar un nucli diferent en un contenidor (ja sigui una versió de Linux diferent o un sistema operatiu diferent).
Atès que estem tractant amb l'aïllament i no amb simple virtualització, la creació de contenidors LXC és més complexa que simplement executar el “debian-installer” en una màquina virtual. Descriurem alguns requisits previs i després passarem a la configuració de la xarxa; llavors podrem crear realment el sistema a executar al contenidor.

12.2.2.1. Passos preliminars

El paquet lxc conté les eines necessàries per executar LXC, i per tant s'ha d'instal·lar.
LXC també requereix el sistema de configuració de control groups, que és un sistema de fitxers virtual que s'ha de muntar a /sys/fs/cgroup. Des que Debian 8 va canviar a systemd, que també es basa en grups de control, això es fa automàticament en temps d'arrencada sense més configuració.

12.2.2.2. Configuració de xarxa

L'objectiu d'instal·lar LXC és crear màquines virtuals; encara que podríem, per descomptat, mantenir-les aïllades de la xarxa, i comunicar-nos amb elles només a través del sistema de fitxers, la majoria dels casos d'ús impliquen donar almenys accés mínim a la xarxa als contenidors. En el cas típic, cada contenidor obtindrà una interfície de xarxa virtual, connectada a la xarxa real a través d'un pont («bridge»). Aquesta interfície virtual es pot connectar directament a la interfície de xarxa física de l'amfitrió (en aquest cas el contenidor està directament a la xarxa), o a una altra interfície virtual definida a l'amfitrió (i llavors l'amfitrió pot filtrar o encaminar el trànsit). En tots dos casos, es requerirà el paquet bridge-utils.
El cas simple és només una qüestió d'editar /etc/network/interfaces, movent la configuració de la interfície física (per exemple, eth0 o enp1s0) a una interfície de pont (normalment br0), i configurar l'enllaç entre ells. Per exemple, si el fitxer de configuració de la interfície de xarxa conté inicialment entrades com les següents:
auto eth0
iface eth0 inet dhcp
Han de ser desactivades i substituïdes per les següents:
auto br0
iface br0 inet dhcp
    bridge-ports eth0
L'efecte d'aquesta configuració serà similar al que s'obtindrà si els contenidors fossin màquines connectades a la mateixa xarxa física que l'amfitrió. La configuració de “pont” gestiona el trànsit de les trames Ethernet entre totes les interfícies pont, que inclou la física eth0, així com les interfícies definides per als contenidors.
En els casos en què aquesta configuració no es pot utilitzar (per exemple, si no es pot assignar cap adreça IP pública als contenidors), es crearà una interfície virtual tap i es connectarà al pont. La topologia de xarxa equivalent es converteix en la d'un amfitrió amb una segona targeta de xarxa connectada en un commutador separat, amb els contenidors també connectats en aquest commutador. L'amfitrió ha d'actuar com a porta d'entrada per als contenidors si estan destinats a comunicar-se amb el món exterior.
A més de bridge-utils, aquesta configuració "rica" requereix el paquet vde2; el fitxer /etc/network/interfaces llavors esdevé:
# 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
La xarxa es pot configurar estàticament als contenidors, o dinàmicament amb un servidor DHCP executant-se a l'amfitrió. Aquest servidor DHCP haurà de ser configurat per respondre les consultes a la interfície br0.

12.2.2.3. Configuració del sistema

Configurem ara el sistema de fitxers que ha d'utilitzar el contenidor. Com que aquesta “màquina virtual” no s'executarà directament al maquinari, es requereixen alguns ajustos en comparació amb un sistema de fitxers estàndard, especialment pel que fa al nucli, dispositius i consoles. Afortunadament, el paquet lxc inclou scripts que pràcticament automatitzen aquesta configuració. Per exemple, les següents ordres (que requereixen els paquets debootstrap i rsync) instal·laran un contenidor Debian:
# 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...
[...]
# 
Tingueu en compte que el sistema de fitxers es crea inicialment a /var/cache/lxc, i després es mou al seu directori de destinació. Això permet crear contenidors idèntics molt més ràpidament, ja que només cal copiar.
Tingueu en compte que l'script de creació de plantilles de Debian accepta una opció --arch per especificar l'arquitectura del sistema a instal·lar i una opció --release si voleu instal·lar alguna cosa diferent de l'actual versió estable de Debian. També podeu establir la variable d'entorn MIRROR per apuntar a un mirall local de Debian.
El paquet lxc també crea una interfície de pont lxcbr0, que per defecte és utilitzat per tots els contenidors de nova creació via /etc/lxc/default.conf i el servei lxc-net:
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
Aquestes entrades signifiquen, respectivament, que es crearà una interfície virtual a cada nou contenidor; que s'activarà automàticament quan s'iniciï el contenidor, i que es connectarà automàticament al pont lxcbr0 de l'amfitrió. Trobareu aquests paràmetres a la configuració creada per al contenidor (/lxc/testlxc/config), on també l'adreça MAC del dispositiu estarà especificada amb lxc.net.0.hwaddr. Si aquesta darrera entrada no es troba o està desactivada, es generarà una adreça MAC aleatòria.
Una altra entrada útil en aquest fitxer és la configuració del nom de l'amfitrió:
lxc.uts.name = testlxc
El nou sistema de fitxers creat ara conté un sistema Debian mínim i una interfície de xarxa.

12.2.2.4. Inici del contenidor

Ara que la nostra imatge de màquina virtual està preparada, iniciem el contenidor amb lxc-start --name=testlxc.
En els llançaments d'LXC posteriors a 2.0.8 les contrasenyes del superusuari no s'estableixen per defecte. Se'n pot establir una executant lxc-attach -n testlxc passwd si vonguéssim. Ara podem iniciar la sessió amb:
# 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:~# 
Ara estem dins del contenidor; el nostre accés als processos està restringit només als iniciats des del mateix contenidor, i el nostre accés al sistema de fitxers està igualment restringit al subconjunt dedicat del sistema de fitxers complet (/var/lib/lxc/testlxc/rootfs). Podem sortir de la consola amb Control+a q.
Tingueu en compte que hem executat el contenidor com un procés en segon pla gràcies a lxc-start engegant usant l'opció --daemon per defecte. Podem aturar el contenidor amb una ordre com lxc-stop --name=testlxc.
El paquet lxc conté un script d'inicialització que pot iniciar automàticament un o diversos contenidors quan l'amfitrió s'inicia (es basa en lxc-autostart que inicia contenidors que tenen l'opció lxc.start.auto establerta a 1). Un control més refinat de l'ordre d'inici és possible amb lxc.start.order i lxc.group: per defecte, l'script d'iniciació engega primer els contenidors que formen part del grup onboot i després els contenidors que no formen part de cap grup. En ambdós casos, l'ordre dins d'un grup es defineix per l'opció lxc.start.order.

12.2.3. Virtualització amb KVM

KVM, que significa «Kernel-based Virtual Machine» o “màquina virtual basada en el nucli”, és abans de res un mòdul de nucli que proporciona la major part de la infraestructura que pot ser utilitzada per un virtualitzador, però no és un virtualitzador per si mateix. El control real de la virtualització es gestiona mitjançant una aplicació basada en QEMU. No us preocupeu si aquesta secció esmenta ordres qemu-*: encara estem parlant de KVM.
A diferència d'altres sistemes de virtualització, el KVM es va fusionar amb el nucli de Linux des del principi. Els seus desenvolupadors van optar per aprofitar els conjunts d'instruccions del processador dedicats a la virtualització (Intel-VT i AMD-V), fet que manté el KVM lleuger, elegant i poc demandant de recursos. La contrapartida, per descomptat, és que el KVM no funciona en cap ordinador, sinó només en aquells amb processadors adequats. Per als ordinadors basats en x86 es pot verificar que teniu un processador així buscant “vmx” o “svm” en les marques de la CPU llistades a /proc/cpuinfo.
Amb Red Hat recolzant activament el seu desenvolupament, KVM s'ha convertit més o menys en la referència per a la virtualització amb Linux.

12.2.3.1. Passos preliminars

A diferència d'eines com VirtualBox, el mateix KVM no inclou cap interfície d'usuari per crear i gestionar màquines virtuals. El paquet virtual qemu-kvm només proporciona un executable capaç d'iniciar una màquina virtual, així com un script d'inicialització que carrega els mòduls apropiats del nucli.
Afortunadament, Red Hat també proporciona un altre conjunt d'eines per resoldre aquest problema desenvolupant la biblioteca libvirt i les eines associades virtual machine manager. El libvirt permet la gestió de màquines virtuals de manera uniforme, independentment del sistema de virtualització involucrat per sota (actualment suporta QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare i UML). virt-manager és una interfície gràfica que utilitza libvirt per crear i gestionar màquines virtuals.
Primer instal·lem els paquets necessaris, amb apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system proporciona el dimoni libvirtd, que permet (potencialment de manera remota) la gestió de les màquines virtuals que s'executen al servidor, i inicia les màquines virtuals requerides quan el servidor s'inicia. libvirt-clients proporciona l'eina de línia d'ordres virsh, que permet controlar les màquines gestionades amb libvirtd.
El paquet virtinst proporciona virt-install, que permet crear màquines virtuals des de la línia d'ordes. Finalment, virt-viewer permet accedir a la consola gràfica d'una màquina virtual.

12.2.3.2. Configuració de xarxa

Igual que amb Xen i LXC, la configuració de xarxa més freqüent implica un pont que agrupa les interfícies de xarxa de les màquines virtuals (vegeu Secció 12.2.2.2, «Configuració de xarxa»).
Alternativament, i en la configuració per defecte proporcionada pel KVM, la màquina virtual té una adreça privada (en el rang 192.168.122.0/24), i el NAT està configurat perquè la màquina virtual pugui accedir a la xarxa exterior.
La resta d'aquesta secció assumeix que l'amfitrió té una interfície física eth0 i un pont br0, i que el primer està connectat en aquest últim.

12.2.3.3. Instal·lació amb virt-install

La creació d'una màquina virtual és molt similar a la instal·lació d'un sistema normal, excepte que les característiques de la màquina virtual es descriuen en una línia de comandament aparentment interminable.
A la pràctica, això significa que utilitzarem l'instal·lador de Debian, arrencant la màquina virtual en una unitat de DVD-ROM virtual que s'associa amb una imatge de DVD de Debian emmagatzemada en el sistema local. La màquina virtual exportarà la seva consola gràfica sobre el protocol VNC (vegeu Secció 9.2.2, «Ús d'escriptoris gràfics remots» per detalls), que ens permetrà controlar el procés d'instal·lació.
Primer hem de dir-li a libvirtd on desar les imatges de disc, llevat que la ubicació per defecte (/var/lib/libvirt/images/) ja ens vagi bé.
# mkdir /srv/kvm
# virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created

# 
Comencem ja el procés d'instal·lació de la màquina virtual i mirem més de prop les opcions més importants de virt-install. Aquesta ordre registra la màquina virtual i els seus paràmetres a libvirtd, i després l'engega perquè la instal·lació pugui continuar.
# virt-install --connect qemu:///system  1
               --virt-type kvm           2
               --name testkvm            3
               --memory 2048             4
               --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10  5
               --cdrom /srv/isos/debian-11.2.0-amd64-netinst.iso  6
               --network bridge=virbr0   7
               --graphics vnc            8
               --os-type linux           9
               --os-variant debiantesting


Starting install...
Allocating 'testkvm.qcow'

1

L'opció --connect especifica l'“hipervisor” a utilitzar. La seva forma és la d'un URL que conté un sistema de virtualització (xen://,qemu://,lxc://,openvz://,vbox://, etc.) i la màquina que hauria d'acollir la màquina virtual (això es pot deixar buit en el cas de l'amfitrió local). A més d'això, i en el cas QEMU/KVM, cada usuari pot gestionar màquines virtuals que treballen amb permisos restringits, i el camí d'URL permet diferenciar les màquines del “sistema” (/system) de les altres (/session).

2

Com que el KVM es gestiona de la mateixa manera que el QEMU, el --virt-type kvm permet especificar l'ús del KVM tot i que l'URL sembla QEMU.

3

L'opció --name defineix un nom (únic) per a la màquina virtual.

4

L'opció --memory permet especificar la quantitat de RAM (en MB) per assignar a la màquina virtual.

5

El --disk especifica la ubicació del fitxer d'imatge que representa el disc dur de la nostra màquina virtual; aquest fitxer es crea, llevat que ja estigui present, amb una mida (en GB) especificada pel paràmetre size. El format permet triar entre diverses maneres d'emmagatzemar el fitxer d'imatge. El format per defecte (qcow2) permet començar amb un petit fitxer que només creix quan la màquina virtual comença realment a utilitzar espai.

6

L'opció --cdrom s'utilitza per indicar on trobar el disc òptic a utilitzar per a la instal·lació. La ruta pot ser un camí local d'un fitxer ISO, un URL d'on es pot obtenir el fitxer, o el fitxer de dispositiu d'una unitat de CD-ROM física (és a dir, /dev/cdrom).

7

El --network especifica com s'integra la targeta de xarxa virtual a la configuració de la xarxa de l'amfitrió. El comportament per defecte (que hem forçat explícitament en el nostre exemple) és integrar-lo en qualsevol pont de xarxa preexistent. Si no existeix cap pont, la màquina virtual només podrà arribar a la xarxa física a través de NAT, de manera que obté una adreça en un rang de subxarxa privat (192.168.122.0/24).
La configuració de xarxa predeterminada, que conté la definició per a una interfície de pont virbr0, es pot editar utilitzant virsh net-edit default i es iniciar via virsh net-start default si no s'ha fet ja automàticament durant l'inici del sistema.

8

--graphics vnc indica que la consola gràfica hauria d'estar disponible utilitzant VNC. El comportament per defecte del servidor VNC associat és només escoltar a la interfície local; si el client VNC s'executarà en un ordinador diferent, establir la connexió requerirà la creació d'un túnel SSH (vegeu Secció 9.2.1.4, «Creació de túnels encriptats amb reenviament de ports»). Alternativament, --graphics vnc,listen=0.0.0.0 es pot utilitzar perquè el servidor VNC sigui accessible des de totes les interfícies; tingueu en compte que si ho feu haureu de configurar el tallafocs en conseqüència.

9

Les opcions --os-type i --os-variant permeten optimitzar alguns paràmetres de la màquina virtual, basant-se en algunes de les característiques ja conegudes del sistema operatiu mencionat.
La llista completa dels tipus de sistemes operatius es pot veure utilitzant l'ordre osinfo-query os del paquet libosinfo-bin.
En aquest punt, la màquina virtual s'està executant, i hem de connectar-nos a la consola gràfica per continuar amb el procés d'instal·lació. Si l'operació anterior s'executava des d'un entorn gràfic d'escriptori, aquesta connexió s'hauria d'iniciar automàticament. Si no, o si operem remotament, virt-viewer es pot executar des de qualsevol entorn gràfic per obrir la consola gràfica (tingueu en compte que la contrasenya de root de la màquina remot es demana dues vegades perquè l'operació requereix dues connexions SSH):
$ virt-viewer --connect qemu+ssh://root@server/system testkvm
root@server's password: 
root@server's password: 
Connexió amb la sessió de l'instal·lador usant virt-viewer

Figura 12.1. Connexió amb la sessió de l'instal·lador usant virt-viewer

Quan s'acaba el procés d'instal·lació, es reinicia la màquina virtual, ara ja llesta per a utilitzar.

12.2.3.4. Gestió de màquines amb virsh

Ara que la instal·lació ha acabat, vegem com manejar les màquines virtuals disponibles. El primer que s'ha d'intentar és demanar a libvirtd la llista de les màquines virtuals que gestiona:
# virsh -c qemu:///system list --all
 Id Name                 State
----------------------------------
  8 testkvm              shut off
Engeguem la nostra màquina virtual de prova:
# virsh -c qemu:///system start testkvm
Domain testkvm started
Ara podem obtenir les instruccions de connexió per a la consola gràfica (la pantalla VNC retornada es pot passar com a paràmetre a vncviewer):
# virsh -c qemu:///system vncdisplay testkvm
127.0.0.1:0
Altres subordres disponibles de virsh inclouen:
  • reboot per reiniciar una màquina virtual;
  • shutdown per activar una aturada ordenada;
  • destroy, per aturar-la sobtadament;
  • suspend per pausar-la;
  • resume per reprendre-la;
  • autostart per activar (o desactivar, amb l'opció --disable) l'inici de la màquina virtual automàticament quan s'inicia l'amfitrió;
  • undefine per eliminar de libvirtd totes les traces de la màquina virtual.
Totes aquestes subordres prenen un identificador de màquina virtual com a paràmetre.