Nel precedente articolo “Introduzione alla virtualizzazione con KVM” sono stati introdotti gli aspetti base della virtualizzazione basata su KVM.
In questo articolo vedremo come implementare una completa soluzione di Virtualizzazione basata su KVM e Debian.

In particolare useremo Debian Squeeze, l’attuale release stable di Debian.

Prerequisiti

Per utilizzare KVM è necessario avere un processore dotato di estensioni per la virtualizzazione, per verificare che siano presenti è sufficiente lanciare il seguente comando:

# egrep -c '(vmx|svm)' /proc/cpuinfo
8

Se il comando (come nell’esempio) restituisce “1″ o un numero maggiore le estensioni sono state rilevate, mentre se restituisce 0, significa che il vostro processore non dispone di tali estensioni, quindi dovrete usare una soluzione differente come ad esempio Xen o VirtualBox.

Nel caso in cui vogliate creare VirtualMachine con un quantitativo di RAM superiore ai 2 GB è necessario avere un processore con architettura X86-64. Anche in questo caso possiamo estrarre questa informazione dal file /proc/cpuinfo:

# egrep -c ' lm ' /proc/cpuinfo
8

Anche in questo caso, se il comando (come nell’esempio) restituisce un numero diverso da 0, il vostro processore potrà eseguire software a 64 bit.

L’ulteriore componente in gioco è il kernel del vostro sistema, che deve essere compilato con il supporto ai 64 bit, per controllare è sufficiente lanciare ‘uname’:

# uname -m
x86_64

che dovrà restituire appunto “x86_64″.
Nel caso il vostro processore sia a 64 bit ma sistema operativo installato a 32, non preoccupatevi, non è necessario effettuare una nuova installazione. Linux infatti è in grado di far girare uno userland a 32 bit su un kernel a 64 bit e nei repository Debian per l’architettura i386 è presente proprio il pacchetto che ci interessa, installabile con un colpo di Apt:

# apt-get install linux-image-2.6-amd64

Al contrario delle estensioni per la virtualizzazione, non avere un processore x86_64 non pregiudica la funzionalità di KVM, semplicemente si potranno creare macchine virtuali con al massimo 2 Gb di RAM, quantitativo più che sufficiente per macchine virtuali di test.

Come ultimo prerequisito è necessario procurarsi un client VNC da installare sulla propria workstation, in questo caso si può proprio dire che uno vale l’altro, l’uso che se ne farà è davvero semplice e non richiede alcuna caratteristica avanzata.

Installazione e configurazione

Il processo di installazione è davvero molto semplice:

# apt-get install qemu-kvm libvirt-bin

APT scaricherà tutti i pacchetti necessari per preparare il vostro sistema alla virtualizzazione.

È possibile fare in modo che un utente non privilegiato possa creare e gestire le VM semplicemente aggiungendo l’utente al gruppo ‘libvirt’:

# adduser fpedrini libvirt

ed effettuare nuovamente la login al sistema per acquisire il nuovo gruppo.

Per verificare che tutto sia funzionante è necessario utilizzare il comando virsh, parte del pacchetto libvirt-bin:

# virsh --connect qemu:///system list

che mostrerà un output simile al seguente:

 Id Name                 State
----------------------------------
 
#

virsh è una shell interattiva che permette di gestire il proprio ambiente di virtualizzazione indipendentemente dall’Hypervisor (vedi precedente articolo) utilizzato, di cui comunque parleremo in maniera approfondita più avanti.

Come ultimo passo, per fare in modo che le virtual machine possano connettersi alla stessa rete presso cui il server è collegato, sarà necessario creare un bridge. Viceversa è possibile sfruttare le reti interne gestite da virsh via libvirt, ma questo tipo di configurazione non è trattata in questo articolo.
Per creare un bridge è necessario installare il pacchetto bridge-utils:

# apt-get install bridge-utils

E’ quindi sufficiente modificare la configurazione delle interfacce di rete in /etc/network/interfaces, creando una nuova stanza all’interno del file e fare in modo che l’interfaccia primaria diventi il bridge (per esempio br0):

auto br0
iface br0 inet static
        address 192.168.0.100
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

Oltre alle normali opzioni (address/network/broadcast/netmask e gateway) sono presenti anche le opzioni usate per la creazione del bridge, e la più importante è bridge_ports, che indica al sistema quale interfaccia fisica deve essere usata per la costruzione del bridge.

Riavviando il servizio di networking:

# /etc/init.d/networking restart

il bridge verrà attivato.

Creazione della prima Macchina Virtuale

Una volta installati i vari pacchetti necessari per la virtualizzazione e configurata la rete è possibile installare la prima virtual machine, sfruttando il comando virt-install.

Virt-install e’ un tool della suite di libvirt che permette di automatizzare i passaggi di base necessari alla creazione della VM, come ad esempio la creazione del file che fungerà da disco virtuale o la configurazione del file XML che contiene la definizione della Virtual Machine.

Se ad esempio volessimo installare una VM che faccia girare una nuova istanza di Debian Squeeze, il comando da lanciare sarà simile al seguente:

# virt-install --connect qemu:///system -n squeeze-vm -r 512 --vcpus=2 --disk path=/virtuals/squeeze-vm10.img,size=10 -c /dev/cdrom --vnc --noautoconsole --os-type linux --os-variant debiansqueeze --accelerate  --hvm --network=bridge:br0

Quello che all’inizio può sembrare un comando difficile e complesso, si rivela in realtà una lista di opzioni abbastanza facile da ricordare quando se ne conosce il significato:

• –connect qemu:///system indica a virt-install quale deve essere l’hypervisor target
• -n indica il nome della Virtual Machine, in questo caso squeeze-vm
• -r indica il quantitativo della ram virtuale in megabytes
• –vcpus=2 indica il quantitativo di cpu virtuali da assegnare alla VM. Test prestazionali indicano che su processori multicore come quelli odierni, assegnare più di due vcpu ad un sistema guest non porta ad alcun aumento di performance. Il numero di processori dedicati infatti serve semplicemente a far capire al sistema guest che sta girando in un ambiente SMP. Ci penserà l’hypervisor a dividere il carico sui core del sistema host
• –disk-path=/virtuals/squeeze-vm,size=10 indica a virt-install dove creare l’immagine per il disco virtuale e la sua dimensione. Può anche essere usato un dispositivo a blocchi (come ad esempio /dev/sdb1, la prima partizione del secondo disco del sistema host o un volume LVM), in questo caso l’opzione size non avrà alcun effetto.
• -c /dev/cdrom indica a virt-install il path dell’immagine di installazione del sistema guest. È possibile utilizzare anche un normale file .iso
• –vnc indica a virt-install di abilitare la console VNC non appena la macchina virtuale è stata creata.
• –os-type linux –os-variant debiansqueeze indicano a virt-install che tipo di sistema operativo verrà installato sul guest
• –accelerate –hvm indica a virt-install che il guest dovrà sfruttare l’accelerazione fornita da KVM. Ricordiamo che in realtà Qemu e KVM sono legati a doppio filo e il secondo può essere visto come un acceleratore per Qemu. inoltre la seconda opzione specifica che il guest dovrà essere un sistema completamente virtualizzato (e non paravirtualizzato come succederebbe con Xen)
• –network=bridge:br0 indica a virt-install quale sarà il bridge da usare per connettere questa virtual machine alla rete

Una volta premuto invio, l’output si presenterà in maniera simile alla seguente:

Starting install...
Creating domain...                                                                                                                                                      |    0 B     00:00     
Domain installation still in progress. Waiting for installation to complete.

a questo punto collegandosi mediante un client VNC (ad esempio vncviewer) al server è possibile completare l’installazione via console, come se si trattasse di una normale installazione Debian.

Dal momento che VNC non è un protocollo cifrato, è preferibile utilizzare un tunnel SSH (come spiegato in questo articolo) dalla propria workstation al server di virtualizzazione, puntando quindi il proprio client VNC alla porta aperta dal tunnel su localhost.

Gestione delle Virtual Machine

Gestire le virtual machine è possibile sempre mediante la comoda shell interattiva virsh di cui è stato fatto cenno poco sopra.

Virsh è il tool principe per la gestione delle macchine virtuali in quanto permette di eseguire con semplicità anche i compiti più complessi tramite una comoda interfaccia testuale.

Per lanciare virsh sarà necessario lanciare il comando:

# virsh --connect qemu:///system

Si presenterà quindi una vera e propria shell interattiva:

Welcome to virsh, the virtualization interactive terminal.
 
Type:  'help' for help with commands
       'quit' to quit
 
virsh #

Per ottenere la lista dei comandi disponibili è sufficiente scrivere help:

virsh # help
Commands:
 
    help            print help
    attach-device   attach device from an XML file
    attach-disk     attach disk device
    attach-interface attach network interface
    autostart       autostart a domain
    capabilities    capabilities
    cd              change the current directory
    connect         (re)connect to hypervisor
    ....
    version         show version
    vncdisplay      vnc display
    snapshot-create Create a snapshot
    snapshot-current Get the current snapshot
    snapshot-delete Delete a domain snapshot
    snapshot-dumpxml Dump XML for a domain snapshot
    snapshot-list   List snapshots for a domain
    snapshot-revert Revert a domain to a snapshot

I comandi disponibili per virsh sono moltissimi e permettono di gestire qualsiasi aspetto di una macchina virtuale, dal suo stato, alla gestione dei dischi virtuali, fino alla gestione delle reti interne.

I comandi sicuramente più utilizzati sono quelli relativi all’esecuzione di un guest, cioè list,start, shutdown e reboot, destroy, suspend e resume.

Tutti questi comandi risultano abbastanza autoesplicativi e, ad eccezione di list tutti necessitano del nome del sistema guest su cui dovranno agire. Il comando list invece accetta due parametri: –all e –inactive, che agiranno come filtri per visualizzare rispettivamente tutte le virtual machine o i soli guest inattivi, se invocato senza alcun parametro, verrà visualizzato l’elenco delle macchine virtuali avviate.

Come detto sopra, i comandi risultano abbastanza chiari, ma è bene fare attenzione ad un paio di dettagli, vediamo con ordine:

• start è sicuramente il più semplice, permette di avviare la virtual machine. In aggiunta, è utile citare il comando autostart che permette di comunicare a libvirt di avviare automaticamente le virtual machine all’avvio del sistema.
• shutdown permette di inviare al sistema guest un segnale di shutdown, simulando ciò che accade sulle macchine fisiche quando viene premuto il tasto di accensione
• reboot invia alla macchina virtuale il segnale di reboot che avvierà un processo di riavvio pulito del sistema.
• destroy fa in modo che il processo della virtual machine venga ucciso. Dal punto di vista della virtual machine questo è l’equivalente di un blackout, la corrente viene interrotta bruscamente. Ovviamente come succede per le macchine reali, questo comando potrebbe creare inconsistenze sul filesystem del guest anche se ovviamente non causerà alcun danno reale all’hardware
• suspend fa in modo che l’esecuzione della virtual machine venga interrotta. La ram rimarrà comunque occupata, ma la macchina virtuale non occuperà più alcuna risorsa relativa a CPU, HD e rete fino al resume.
• resume permette di far uscire la virtual machine dallo stato di ibernazione attivato con suspend

Menzione particolare meritano anche i comandi save e restore.
Save richiede, oltre al nome della virtual machine anche un parametro aggiuntivo, cioè il filename dove salvare lo stato del sistema guest. Al contrario di suspend, questo comando permette di salvare tutto ciò che concerne la virtual machine (ram, registri del processore, interrupts, eccetera, eccetera…) in un file, e terminare il processo del sistema guest. Questo fa si che una Virtual Machine possa essere spostata completamente da un host all’altro senza che il sistema e le applicazioni al suo interno ne risentano minimamente.
Restore, come la sua controparte richiede come parametro aggiuntivo il file da cui leggere lo stato della virtual machine da ripristinare.

Conclusioni

Questo articolo, per quanto lungo, rimane sempre e comunque una rapida introduzione al vasto argomento della virtualizzazione, tematica che grazie ai recenti miglioramenti di libvirt e dei tool a corredo sta diventando sempre più vasta e interessante.

Ciò nonostante credo che usando come base le informazioni qui contenute si possano creare ambienti di virtualizzazione in grado di competere (e in parecchi casi persino surclassare) le soluzioni di virtualizzazione proprietarie più blasonate.

Basti pensare che i grandi player del mondo della virtualizzazione (Amazon, RackSpace e Google, giusto per citare i più grandi) utilizzano soluzioni basate proprio sui software descritti in questo articolo.

La virtualizzazione è una tecnologia che sta prendendo sempre più piede nell’informatica moderna grazie alla diffusione di hardware sempre più potente, in grado di far girare più sistemi operativi in maniera concorrente.

In questo articolo introdurremo i concetti di base della virtualizzazione e ci soffermeremo su KVM, uno dei progetti liberi più attivi nel campo della virtualizzazione.

Pro e contro della virtualizzazione

La virtualizzazione che in quest’ultimo periodo occupa un sacco di spazio sulle riviste specializzate e sembra essere l’ultimo baluardo tecnologico, è in realtà una tecnologia che ha origini addirittura negli anni ’60, nei laboratori di IBM dove nacque il CP-40, precursore del sistema CP-67 e di tutta la “VM Family” di IBM, che era alla base dei sistemi operativi per i mainframe IBM s370 prima e s390 dopo.

Ma come mai solo ora la virtualizzazione (e il suo diretto discendente il Cloud Computing) sta tornando così di moda e occupa in maniera prepotente una fetta sempre più grande del mercato?

Come accennato poco sopra, ogni mese l’hardware diventa sempre più potente ed economico, basti pensare all’evoluzione dei processori che dai modelli single core di pochi anni fa siamo arrivati a sei core impacchettati sul singolo processore.

Grazie a questa potenza smisurata, siamo in grado di poter far girare più sistemi operativi sullo stesso hardware in maniera concorrente, senza dover ogni volta riavviare per passare da un sistema all’altro, tramite tecniche di virtualizzazione.

Come dice il nome stesso, la virtualizzazione permette di creare dei sistemi virtuali all’interno del sistema operativo vero e proprio, in modo da far girare un qualsiasi sistema operativo su dell’hardware virtuale messo a disposizione del sistema di virtualizzazione.

In questo modo, avendo abbastanza risorse hardware a disposizione potremo far girare sulle nostre workstation una serie sterminata di virtual machine con i più disparati sistemi operativi, da varie distribuzioni Linux ad altri sistemi proprietari come Windows e MacOs (a patto di rispettare le licenze, ovviamente!).

Il vantaggio più grande è proprio quello di poter disporre di sistemi di test per i più svariati usi, ad esempio uno sviluppatore potrà testare i propri software sui vari sistemi senza avere una pletora di installazioni diverse, mentre un sistemista potrà testare diverse configurazioni in tutta tranquillità senza dover cercare server per creare gli ambienti di test.

Se ci spostiamo invece su ambienti più grandi, come quelli aziendali, la virtualizzazione permette di ridurre i costi e consolidare la propria infrastruttura aziendale, accorpando su un sistema fisico più macchine virtuali, in modo da ridurre sia il costo dell’hardware che i consumi energetici (che spesso e volentieri sono la spesa più grande del reparto IT delle aziende).
Il cloud computing porta addirittura al limite il concetto di virtualizzazione, creando pool di risorse virtuali sparse su vari nodi, proprio nell’ottica di sfruttare sempre meglio le risorse inutilizzate dei vari server.

Ovviamente non è tutto oro quello che luccica, virtualizzare un sistema, specialmente quando si tratta di server, pone seri problemi di performance e ridondanza, visto che bisogna calcolare con molta precisione quante macchine virtuali potranno essere ospitate dal singolo sistema di virtualizzazione per evitare di sovraccaricare la macchina fisica e avere performance poco soddisfacenti, e predisporre sistemi di migrazione automatici delle virtual machine su altri nodi di virtualizzazione per evitare che in caso di guasto hardware si perda una serie di servizi che possono essere vitali, ma questi sono temi decisamente avanzati rispetto allo scopo di questo articolo.

KVM in dettaglio

KVM sta per Kernel-based Virtual Machine e, come dice il nome, è composto da un modulo integrato nel kernel linux (dalla release 2.6.20) che permette di sfruttare le estensioni di virtualizzazione dei processori moderni.

Di per sè KVM non effettua nessun tipo di emulazione, si limita ad attivare le estensioni della CPU e a mettere a disposizione dello userspace un dispositivo in grado di riservare le risorse hardware da mettere a disposizione dei sistemi virtuali.
Un programma userspace (in particolare le libvirt o QEMU, come vedremo in fase di implementazione nel prossimo articolo) si occuperà di richiedere al modulo di riservare questa o quella risorsa e di svolgere le operazioni necessarie per l’esecuzione della VM.
Inoltre si KVM occupa di aggiungere una terza modalità all’esecuzione del kernel, la Guest Mode.

Normalmente il kernel ha due modalità di esecuzione, la Kernel mode (o Ring0) in cui solo software fidato (quindi, di fatto, solo il kernel) può essere eseguito con la massima priorità per operazioni privilegiate come l’accesso diretto all’hardware, e la User Mode, in cui vengono eseguite tutte le operazioni non privilegiate relative ai programmi userspace.

L’introduzione di KVM ha introdotto la Guest Mode, una modalità particolare in cui il kernel del sistema host (che è il sistema vero e proprio che ospita i sistemi guest, cioè le virtual machine) permette ai kernel dei sistemi virtualizzati di eseguire operazioni privilegiate come l’accesso diretto all’hardware virtuale.

Il punto di forza di KVM sta proprio in questa sua semplicità, il cuore del sistema di virtualizzazione (l’hypervisor come vedremo poco più avanti) svolge poche fondamentali operazioni, mentre tutta la parte di emulazione dell’hardware viene demandata a componenti esterne e specializzate (come le libvirt o Qemu).

La semplicità dell’hypervisor è però legata anche al suo punto debole (se così si può definire) di KVM: la dipendenza da hardware specializzato.
KVM riesce ad essere così semplice e rapido proprio grazie all’utilizzo delle estensioni speciali inserite nei processori x86 di ultima generazione: AMD-V per i processori AMD e VT-x per i processori Intel, senza le quali KVM non può proprio funzionare.

Come funziona

Abbiamo parlato dei vantaggi e svantaggi della virtualizzazione, ed in particolare di KVM, ma esattamente cosa sta sotto a questa meravigliosa tecnologia?
In tutti i sistemi di virtualizzazione dai primi sistemi di IBM (il CP-40 nato alla fine degli anni ’60), passando per Xen, VMWare e KVM troviamo un elemento comune chiamato Hypervisor.

L’hypervisor è quel componente (sia esso hardware come nel CP-40 di IBM o software come avviene oggi) che si inserisce tra i sistemi guest (le virtual machine) e l’hardware sottostante e gestisce i meccanismi di virtualizzazione dell’hardware da mettere a disposizione dei sistemi guest.

Architettura di un sistema di virtualizzazione

Si possono riconoscere due tipologie di hypervisor, i cosiddetti “Native” (o “Bare Metal”) e gli hypervisor “Hosted”.
La prima famiglia è la più anziana e trova le sue origini sempre nei laboratori di IBM: si tratta di un piccolissimo strato di software che gira direttamente su hardware specializzato e permette la gestione dei sistemi host.

I sistemi ‘Hosted’ invece, sono i più giovani, si tratta di hypervisor che girano come processo all’interno di sistemi operativi general purpose, i software di virtualizzazione come VirtualBox o VMWare Workstation ne sono un esempio.

Ovviamente come in tutte le cose la distinzione non è più così netta, KVM ad esempio è un ibrido tra le due famiglie dal momento che necessita sia di hardware specializzato (le estensioni per la virtualizzazione del processore), sia di un sistema operativo che permetta a tutti i suoi compontenti di essere eseguiti.

Architettura di KVM

Come si può vedere dalla figura, la parte dell’hypervisor (in arancione) è divisa in due parti, la prima legata allo userspace, le libvirt e QEMU che si occupano di fornire la parte di emulazione dell’hardware (forniscono cioè i virtual device che verranno visti dai sistemi guest), mentre la seconda risiede all’interno del kernel, il modulo di KVM, l’hypervisor appunto che permette la gestione dell’hardware di virtualizzazione (le famose estensioni VTX e AMD-V) e che espone un device file in /dev/kvm usato per associare i sistemi guest alle risorse assegnate.

Conclusioni

La virtualizzazione è un mercato in continua espansione, sempre più vendor stanno impegnando risorse nella ricerca e nello sviluppo di soluzioni alternative.
In questo calderone di soluzioni emergenti, il primo beneficiario è senza dubbio Linux, che grazie alla sua architettura flessibile sta giocando un ruolo chiave per lo sviluppo di nuove tecnologie come KVM che, assieme a lguest e Xen stanno portando a grossi cambiamenti volti all’incremento di performance di tutto il kernel.