Xen esegue il sistema operativo ospite in un anello di privilegio più basso di quello dell’hypervisor e, sui kernel paravirtualizzati, sostituisce le istruzioni privilegiate con chiamate esplicite (hypercall) al monitor. Da qui parte ogni discorso onesto sulla virtualizzazione in un centro di calcolo: il guadagno dipende da come l’hypervisor intercetta o evita le operazioni privilegiate, e da quanto costa quell’intercettazione.

Queste note nascono mentre preparavo un seminario tecnico su Xen per personale di amministrazioni pubbliche e aziende del settore. Provo a separare ciò che è misurabile e documentato da ciò che, in quei contesti, si dà per scontato.

Contesto e problema

Il centro di calcolo di un ente medio tiene di solito un server fisico per servizio: il file server, la posta, il gestionale, il sito istituzionale, il controller di dominio. Ciascuno usa una frazione di CPU quasi sempre, eppure occupa un alloggiamento, un alimentatore, una porta di rete, una riga nel contratto di manutenzione. La domanda pratica è quanti di quei carichi possano stare sulla stessa macchina senza disturbarsi, e cosa si rompe quando cede l’hardware sotto.

La virtualizzazione risolve entrambe le cose con lo stesso meccanismo: stacca l’immagine del sistema operativo dal ferro su cui gira. Xen lo fa con un hypervisor di tipo 1, che si carica prima del sistema operativo e ne ospita uno privilegiato — il dominio di controllo, dom0 — più i domini ospiti non privilegiati, domU.

Architettura

Xen nasce come progetto di ricerca dell’Università di Cambridge; la descrizione di riferimento è il lavoro presentato a SOSP 2003, Xen and the Art of Virtualization. Nello stesso hypervisor convivono due tecniche, e conviene tenerle distinte.

La paravirtualizzazione richiede un kernel ospite modificato, consapevole di girare sotto un hypervisor. Il kernel non esegue le istruzioni privilegiate sperando che il processore le gestisca: chiama l’hypervisor con una hypercall. Per la memoria, le tabelle delle pagine restano leggibili dall’ospite, ma gli aggiornamenti passano dal monitor, che li convalida. Il costo è che serve un kernel adattato; il vantaggio è che sulle operazioni più frequenti si evita di intercettare ed emulare. Su Linux questo adattamento non è più un albero di patch a parte: l’infrastruttura paravirt_ops è in mainline dal kernel 2.6.23 (2007), e da lì un kernel standard può fare da domU Xen.

L’altra tecnica è l’HVM, hardware virtual machine, disponibile da Xen 3.0. Sfrutta le estensioni di virtualizzazione del processore — Intel VT-x, AMD-V — per eseguire un sistema operativo ospite non modificato, Windows compreso. Qui l’emulazione delle periferiche (disco, rete, video) è affidata a un processo derivato da QEMU, qemu-dm, che gira in dom0. È la strada obbligata quando l’ospite non si può ricompilare, ed è anche la più pesante sull’I/O: ogni accesso a un dispositivo emulato attraversa più transizioni tra ospite, hypervisor e dom0.

Per chi gestisce il centro di calcolo il nodo architetturale è dom0: è il dominio da cui passano il pannello di controllo, i driver reali dei dispositivi e il backend di I/O degli ospiti. Un dom0 saturo o compromesso degrada o blocca tutti i domU che ospita. Il consolidamento sposta il rischio su un punto solo, non lo elimina.

Punto critico: la migrazione a caldo

La funzione che in un seminario fa più effetto è la migrazione a caldo: spostare un dominio in esecuzione da una macchina fisica a un’altra senza spegnerlo. È anche quella su cui girano più numeri inventati, quindi conviene ancorarsi alla fonte.

Il meccanismo è descritto nel lavoro Live Migration of Virtual Machines (Clark e altri, NSDI 2005). Procede per copia iterativa della memoria: l’hypervisor trasferisce alla destinazione tutte le pagine del dominio mentre questo continua a girare, poi ripete il trasferimento per le sole pagine modificate nel frattempo, e itera finché l’insieme delle pagine ancora “sporche” è abbastanza piccolo. A quel punto sospende il dominio per un attimo, copia l’ultimo residuo, e lo riavvia sulla destinazione. Le misure del lavoro danno tempi di indisponibilità del servizio dell’ordine delle decine di millisecondi — circa 60 ms nel caso migliore documentato.

Tre condizioni rendono raggiungibile quella misura, tre vincoli la circoscrivono. Servono: storage condiviso tra origine e destinazione, perché il disco non si copia; una rete a banda larga e bassa latenza tra i due nodi; CPU compatibili, perché si copia lo stato del processore. I vincoli: la migrazione non protegge da un guasto improvviso dell’hardware di origine — è una procedura pianificata, non un meccanismo di alta disponibilità; un dominio che sporca memoria più in fretta di quanto la rete riesca a trasferirla allunga la fase di copia o non converge mai; e l’indisponibilità misurata in laboratorio non è quella che si ottiene su un applicativo reale, con sessioni utente aperte e timeout di rete.

Implicazioni per i costi di gestione

Il consolidamento taglia voci di costo che si possono misurare prima e dopo: numero di server fisici, assorbimento elettrico, calore da dissipare, alloggiamenti in rack, contratti di manutenzione hardware. Sono numeri reali e si contano. Vanno però messi accanto ai costi che il consolidamento introduce: una macchina fisica che ospita dieci domini è un punto di guasto il cui impatto vale per dieci servizi, quindi pretende ridondanza, monitoraggio e procedure di ripristino più serie di quelle che bastavano a dieci scatole indipendenti.

Per un ente pubblico la voce più pesante riguarda chi mantiene il sistema. Xen è software libero, sotto GPL: nessun costo di licenza per l’hypervisor. Ma la competenza per progettare lo storage condiviso, dimensionare dom0, scegliere tra paravirtualizzazione e HVM caso per caso e portare a termine una migrazione senza perdere dati non è gratuita e non si scarica da un sito. È il vero centro di gravità di un’iniziativa di formazione, e la ragione per cui un laboratorio pomeridiano, dove si tocca con mano una migrazione vera, vale più di una mattinata di diapositive. Il ciclo di seminari T-OSSLab che fa da cornice a queste note, organizzato con l’Università di Pisa e il Polo Tecnologico di Navacchio, è raccontato in un insight pubblicato da noze: https://www.noze.it/insights/tosslab-seminari-inizio-2009/.

Limiti

Quanto sopra descrive Xen sui kernel e sulle versioni disponibili oggi, all’inizio del 2009; le percentuali di sovraccarico variano con il carico, il tipo di I/O e l’hardware, e non vanno citate come costanti. La paravirtualizzazione su Linux è matura; l’HVM è la strada per gli ospiti non modificabili, ma paga sull’I/O finché non si affiancano driver paravirtualizzati nell’ospite. E nessuna di queste tecniche sostituisce un piano di continuità: la virtualizzazione rende più facili lo spostamento e la copia di un sistema, da sola non garantisce che resti in piedi.

Immagine di copertina: Schema a blocchi dell’architettura Xen: in alto un riquadro verde “XEN dom0” con app di gestione e driver di dispositivo, accanto due… — diagramma di Radoslaw Korzeniewski, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:XEN-schema.png