xen-create-image, che automatizza gran parte del compito. L'unico parametro obbligatorio è --hostname, che dà un nome al domU; altre opzioni sono importanti, ma possono essere memorizzate nel file di configurazione /etc/xen-tools/xen-tools.conf e la loro mancanza dalla riga di comando non genera un errore. Perciò è importante controllare i contenuti di questo file prima di creare delle immagini oppure, in alternativa, usare parametri aggiuntivi nell'esecuzione di xen-create-image. I parametri importanti includono:
--memory, per specificare la quantità di RAM dedicata al sistema appena creato;
--size e --swap, per definire la dimensione dei "dischi virtuali" disponibili al domU;
--debootstrap-cmd, per specificare il comando debootstrap usato. Il predefinito è debootstrap se sono installati debootstrap e cdebootstrap; in questo caso, verrà usata spesso anche l'opzione --dist (con il nome di una distribuzione come bullseye).
--dhcp dichiara che la configurazione di rete del domU deve essere ottenuta tramite DHCP mentre --ip permette di definire un indirizzo IP statico.
--dir, è di creare un file sul dom0 per ogni dispositivo da rendere disponibile al domU. Per i sistemi che usano LVM, l'alternativa è usare l'opzione --lvm, seguita dal nome di un gruppo di volume; quindi xen-create-image creerà un nuovo volume logico dentro quel gruppo e questo volume logico sarà reso disponibile al domU come disco fisso.
#xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=bullseye --role=udevGeneral 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
vif*, veth*, peth* e xenbr0. L'hypervisor Xen le organizza in qualsiasi configurazione sia stata definita, sotto il controllo degli strumenti nello spazio utente. Poiché le modalità NAT e routing vengono utilizzate in casi particolari, ci occuperemo solo del modello di bridging.
xend è configurato per integrare le interfacce di rete virtuali in qualunque bridge di rete preesistente (con precedenza a xenbr0 se esiste più di un bridge). Bisogna quindi impostare un bridge in /etc/network/interfaces (il che richiede l'installazione del pacchetto bridge-utils, che è il motivo per cui xen-utils lo raccomanda) per sostituire la voce esistente relativa a eth0 (fare attenzione ad utilizzare il nome di dispositivo di rete corretto):
auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0
bridge_maxwait 0xl. Questo comando permette diverse manipolazioni sui domini, fra cui elencarli, avviarli e fermarli. Si potrebbe dover incrementare la memoria predefinita mediante modifica della variabile memory nel file di configurazione (/etc/xen/testxen.cfg, in questo caso). Qui è stata impostata a 1024 (megabyte).
#xl listName ID Mem VCPUs State Time(s) Domain-0 0 3918 2 r----- 35.1 #xl create /etc/xen/testxen.cfgParsing config from /etc/xen/testxen.cfg #xl listName ID Mem VCPUs State Time(s) Domain-0 0 2757 2 r----- 45.2 testxen 3 1024 1 r----- 1.3
testxen usa memoria fisica presa dalla RAM che altrimenti sarebbe disponibile per il dom0, non memoria simulata. Pertanto bisogna fare attenzione, quando si assembla un server che deve ospitare istanze di Xen, a fornire RAM fisica secondo le necessità.
hvc0, con il comando xl console:
#xl console testxen[...] Debian GNU/Linux 11 testxen hvc0 testxen login:
xl pause e xl unpause. Notare che, sebbene un domU in pausa non usi affatto il processore, la memoria ad esso allocata è ancora in uso. Può essere interessante considerare i comandi xl save e xl restore: salvare un domU libera le risorse precedentemente usate da questo domU, compresa la RAM. Al ripristino (o all'uscita dalla pausa, se è per quello) un domU non si accorge di alcunché al di là del passare del tempo. Se un domU era in esecuzione quando il dom0 viene spento, gli script nel pacchetto salvano automaticamente il domU e lo ripristinano all'avvio successivo. Questo ovviamente comporterà i consueti inconvenienti che si riscontrano quando si iberna un computer portatile, per esempio; in particolare, se il domU viene sospeso per troppo tempo, le connessioni di rete possono scadere. Notare inoltre che a tutt'oggi Xen è incompatibile con gran parte della gestione energetica ACPI, il che impedisce di sospendere il sistema host (dom0).
shutdown) o dal dom0, con xm shutdown o xl reboot.
xl richiedono uno o più argomenti, spesso il nome di un domU. Questi argomenti sono ben descritti nella magina di manuale xl(1).
init, e l'insieme che ne risulta è molto simile ad una macchina virtuale. Il nome ufficiale per una impostazione come questa è "contenitore" (da cui il nomignolo LXC: LinuX Containers), ma una differenza piuttosto importante rispetto alle "vere" macchine virtuali come quelle fornite da Xen o KVM è che non c'è un secondo kernel; il contenitore usa lo stesso kernel del sistema host. Questo ha sia dei pro che dei contro: fra i vantaggi ci sono prestazioni eccellenti data la totale assenza di carico aggiuntivo e il fatto che il kernel ha una visione globale di tutti i processi che girano sul sistema, quindi la schedulazione può essere più efficiente rispetto al caso in cui due kernel indipendenti dovessero schedulare diversi insiemi di attività. Il principale svantaggio è l'impossibilità di far girare un diverso kernel in un contenitore (sia una diversa versione di Linux sia un sistema operativo del tutto diverso).
/sys/fs/cgroup. Dal momento che Debian 8 è passata a systemd, che si basa anche su gruppi di controllo, questo ora è fatto automaticamente al boot senza ulteriori configurazioni.
/etc/network/interfaces, spostando la configurazione dell'interfaccia fisica (per esempio eth0 o enp1s0) su un'interfaccia bridge (di solito br0) e configurare il collegamento fra di loro. Per esempio, se il file di configurazione dell'interfaccia di rete contiene inizialmente voci come le seguenti:
auto eth0 iface eth0 inet dhcp
auto br0
iface br0 inet dhcp
bridge-ports eth0eth0 fisica oltre alle interfacce definite per i contenitori.
/etc/network/interfaces allora diventa:
# l'interfaccia eth0 è invariata
auto eth0
iface eth0 inet dhcp
# interfaccia virtuale
auto tap0
iface tap0 inet manual
vde2-switch -t tap0
# Bridge per i contenitori
auto br0
iface br0 inet static
bridge-ports tap0
address 10.0.0.1
netmask 255.255.255.0br0.
#lxc-create -n testlxc -t debiandebootstrap 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... [...] #
/var/cache/lxc e poi spostato nella sua directory di destinazione. Ciò permette di creare contenitori identici molto più rapidamente, visto che a questo punto basta copiarli.
--arch per specificare l'architettura del sistema da installare ed un'opzione --release se si vuole installare qualcos'altro rispetto all'attuale versione stabile di Debian. È anche possibile impostare la variabile d'ambiente MIRROR per puntare ad un mirror locale di Debian.
lxcbr0, che viene usata, in modo predefinito, da tutti i nuovi contenitori creati tramite /etc/lxc/default.conf e il servizio lxc-net:
lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up
lxcbr0 sull'host. Queste impostazioni sono presenti nella configurazione del contenitore creato (/var/lib/lxc/testlxc/config), anche l'indirizzo MAC del dispositivo sarà contenuto in lxc.net.0.hwaddr. Se quest'ultima voce fosse assente o disabilitata, verrà generato un indirizzo MAC casuale.
lxc.uts.name = testlxc
lxc-start --name=testlxc.
lxc-attach -n testlxc passwd. È possibile accedere con:
#lxc-console -n testlxcConnected 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:rootPassword: 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 auxwfUSER 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:~#
/var/lib/lxc/testlxc/rootfs). Si può uscire dalla console con Control+a q.
lxc-start che usa in modo predefinito l'opzione --daemon. Si può interrompere l'esecuzione del contenitore con un comando del tipo lxc-stop --name=testlxc.
lxc-autostart che avvia i contenitori che hanno l'opzione lxc.start.auto impostata a 1). Un controllo più dettagliato dell'ordine di avvio è possibile con lxc.start.order e lxc.group: per impostazione predefinita, lo script di inizializzazione avvia prima i contenitori che fanno parte del gruppo onboot e poi i contenitori che non fanno parte di alcun gruppo. In entrambi i casi, l'ordine all'interno di un gruppo è definito dall'opzione lxc.start.order.
qemu-*: si parla comunque di KVM.
/proc/cpuinfo.
virt-manager è un'interfaccia grafica che usa libvirt per creare e gestire macchine virtuali.
apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system fornisce il demone libvirtd, che permette di gestire (potenzialmente da remoto) le macchine virtuali che girano sull'host e fa partire le VM richieste all'avvio dell'host. libvirt-clients fornisce lo strumento a riga di comando virsh, che permette di controllare le macchine gestite da libvirtd.
virt-install, che permette di creare macchine virtuali da riga di comando. Infine, virt-viewer permette di accedere alla console grafica di una VM.
eth0 e un bridge br0 e che la prima sia connessa al secondo.
libvirtd dove memorizzare le immagini dei dischi, se non va bene la posizione predefinita (/var/lib/libvirt/images/).
#mkdir /srv/kvm#virsh pool-create-as srv-kvm dir --target /srv/kvmPool srv-kvm created #
virt-install. Questo comando registra la macchina virtuale e i suoi parametri in libvirtd, quindi la avvia cosicché la sua installazione può procedere.
#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
Starting install... Allocating 'testkvm.qcow'
|
L'opzione --connect specifica quale "hypervisor" usare. La sua forma è quella di un URL contenente un sistema di virtualizzazione (xen://, qemu://, lxc://, openvz://, vbox:// e così via) e la macchina che deve ospitare la VM (questo può essere lasciato vuoto nel caso dell'host locale). Inoltre e nel caso di QEMU/KVM ciascun utente può gestire macchine virtuali che funzionano con permessi ristretti e il percorso nell'URL permette di differenziare le macchine "di sistema" (/system) dalle altre (/session).
|
|
Poiché KVM è gestito allo stesso modo di QEMU, --virt-type kvm permette di specificare l'uso di KVM anche se l'URL sembra quello di QEMU.
|
|
L'opzione --name definisce un nome (unico) per la macchina virtuale.
|
|
L'opzione --memory permette di specificare la quantità di RAM (in MB) da allocare per la macchina virtuale.
|
| --disk specifica la posizione del file immagine che deve rappresentare il disco fisso della macchina virtuale; quel file è creato, se non presente, con una dimensione (in GB) specificata dal parametro size. Il parametro format permette di scegliere fra vari modi di memorizzare il file immagine. Il formato predefinito (qcow2) permette di iniziare con un file piccolo che cresce solo quando la macchina virtuale comincia effettivamente ad usare spazio.
|
|
L'opzione --cdrom è usata per indicare dove trovare il disco ottico da usare per l'installazione. Il percorso può essere un percorso locale di un file ISO, un URL dove reperire il file o il device di un lettore CD-ROM fisico (es. /dev/cdrom).
|
| --network specifica come la scheda di rete virtuale si integra nella configurazione di rete dell'host. Il comportamento predefinito (che in questo esempio è esplicitamente forzato) è di integrarla in un qualunque bridge di rete preesistente. Se non esiste un tale bridge, la macchina virtuale raggiungerà la rete fisica solo tramite NAT, quindi riceve un indirizzo in un intervallo di una sottorete privata (192.168.122.0/24).
La configurazione di rete predefinita, che contiene la definizione per un'interfaccia bridge virbr0, può essere modificata con virsh net-edit default e avviata con virsh net-start default se non è già stata eseguita automaticamente durante l'avvio del sistema.
|
| --graphics vnc indica che la console grafica deve essere resa disponibile tramite VNC. Il comportamento predefinito per il server VNC associato è di soltanto restare in ascolto sull'interfaccia locale; se il client VNC deve girare su un host diverso, si dovrà impostare un tunnel SSH per stabilire la connessione (vedere Sezione 9.2.1.4, «Creazione di tunnel cifrati con il port forwarding»). In alternativa, si può usare --graphics vnc,listen=0.0.0.0 in modo che il server VNC sia accessibile da tutte le interfacce; notare che in questo caso, sarebbe veramente necessario configurare un firewall di conseguenza.
|
|
Le opzioni --os-type e --os-variant permettono di ottimizzare alcuni parametri della macchina virtuale, basandosi su alcune delle funzionalità note del sistema operativo lì menzionato.
L'elenco completo dei tipi di sistema operativo (OS - Operative System) può essere visualizzato usando il comando osinfo-query os presente nel pacchetto libosinfo-bin.
|
virt-viewer da qualunque ambiente grafico per aprire la console grafica (notare che la password di root dell'host remoto viene chiesta due volte perché l'operazione richiede 2 connessioni SSH):
$virt-viewer --connect qemu+ssh://root@server/system testkvmroot@server's password: root@server's password:
libvirtd la lista delle macchine virtuali che gestisce:
#virsh -c qemu:///system list --all Id Name State ---------------------------------- 8 testkvm shut off
#virsh -c qemu:///system start testkvmDomain testkvm started
vncviewer):
#virsh -c qemu:///system vncdisplay testkvm127.0.0.1:0
virsh includono:
reboot per riavviare una macchina virtuale;
shutdown per provocare uno spegnimento pulito;
destroy per fermarla brutalmente;
suspend per metterla in pausa;
resume per farla uscire dalla pausa;
autostart per abilitare (o disabilitare, con l'opzione --disable) l'avvio automatico della macchina virtuale all'avvio dell'host;
undefine per rimuovere ogni traccia della macchina virtuale da libvirtd.