Il concetto di macchina virtuale ha accompagnato l’ultimo ventennio della storia dell’informatica applicata. In principio per macchina virtuale si intendeva la visione che ciascun utente percepiva del sistema di elaborazione (singolo) a cui aveva accesso; grazie alla virtualizzazione ogni utente del sistema aveva l\’impressione di essere l\’unico ad utilizzare lo stesso, e di conseguenza l\’unico ad avere tutte le risorse a disposizione. Il software capace di fornire questa virtualizzazione viene chiamato Hypervisor. Un prodotto innovativo in questo settore è senza dubbio XEN. Interessante hypervisor (virtual machine monitor) open-source, XEN, sviluppato presso il Computer Laboratory dell\’Università di Cambridge è distribuito sotto licenza GPL. Esso consente di emulare differenti sistemi operativi sulla stessa macchina, contenendo l\’overhead introdotto e offrendo prestazioni interessanti se comparate sia a quelle dei sistemi reali (non emulati) che a quelle offerte dagli altri hypervisors presenti in commercio.
Futuro virtuale
Macchine virtuali
Il concetto di macchina virtuale ha accompagnato l’ultimo ventennio della storia dell’informatica applicata. In principio per macchina virtuale si intendeva la visione che ciascun utente percepiva del sistema di elaborazione (singolo) a cui aveva accesso; grazie alla virtualizzazione ogni utente del sistema aveva l’impressione di essere l’unico ad utilizzare lo stesso, e di conseguenza l’unico ad avere tutte le risorse a disposizione. Il software capace di fornire questa virtualizzazione viene chiamato Hypervisor.
Oggi per macchina virtuale si possono intendere differenti cose:
a) Un programma che emula un calcolatore, come ad esempio la Java Virtual Machine, che emula un calcolatore la cui ISA (Istruction Set Architecture) è composta dalle istruzioni presenti nel bytecode, ossia il frutto della compilazione di un sorgente Java.
b) Un programma che crea un “ambiente applicativo” tale da apparire come un “finto computer”, su cui si potrà installare un sistema operativo diverso da quello che equipaggia il vero elaboratore.
La tecnica della virtualizzazione rappresenta dunque una pietra miliare di notevole importanza nell’evoluzione delle architetture informatiche. Si è partiti con la virtualizzazione di risorse hw, quali possono essere le periferiche di un semplice computer, alla base del concetto di S.O. e si è giunti alla virtualizzazione di risorse sw, anche di notevole complessità, quali i sistemi operativi.
Xen
Un prodotto innovativo in questo settore è senza dubbio XEN. Interessante hypervisor (virtual machine monitor) open-source, XEN, sviluppato presso il Computer Laboratory dell’Università di Cambridge è distribuito sotto licenza GPL. Esso consente di emulare differenti sistemi operativi sulla stessa macchina, contenendo l’overhead introdotto e offrendo prestazioni interessanti se comparate sia a quelle dei sistemi reali (non emulati) che a quelle offerte dagli altri hypervisors presenti in commercio.
Le caratteristiche principali di questo prodotto sono le seguenti:
1. completamente open-source: offre la possibilità a ciascun sviluppatore di ideare soluzioni ad hoc per il dominio applicativo di interesse;
2. compliance con i più comuni S.O.: tra essi Windows, Linux, BSD, Solaris;
3. virtualizzazione di seconda generazione:
– supporto alla paravirtualizzazione
– virtualizzazione di piattaforme x86 ARM e IA64 tramite il supporto dei big del settore, quali Intel e AMD;
– supporto all’elaborazione a 64-bit;
– supporto alle tecniche di virtualizzazione hardware proposte da Intel e AMD, note rispettivamente come Intel VT and AMD-V;
4. supporto da parte dei grandi vendors operanti nel settore ICT; tra essi: Amazon Web Services, Citrix, Fujitsu, Intel, Lenovo, Neocleus, Novell, Oracle, Sun Microsystems, e Virtual Iron;
5. CPU portability: XEN consente di trasportare in maniera assolutamente trasparente una macchina virtuale da esso gestita, sulla quale è attiva un’istanza di un S.O., da una istanza di XEN a un’altra, in esecuzione su due macchine fisiche distinte;
6. Power saving: XEN è stato progettato in modo tale da monitorare e gestire il consumo di energia, minimizzando gli sprechi;
7. Sicurezza: XEN isola i processi di security management gestendoli in sessioni virtuali separate; in questo modo innalza il livello di sicurezza, prevenendo operazioni di hacking;
8. business continuity: XEN introduce al suo interno tecniche di dynamic provisioning che, in caso di server failures, permettono di migrare verso un pool di risorse server di backup in meno di 100 ms;
9. Xen.org: il progetto XEN è supportato da una community su web molto estesa, con numerosi sviluppatori sparsi in tutto il mondo. Molti sono anche i progetti di ricerca nati in varie università e centri di ricerca, basati su XEN. Il portale dedicato all’hypervisor presenta una sezione completamente dedicata agli sviluppatori e ai progetti in corso di realizzazione, nonchè a quelli già realizzati.
Architettura di Xen
Xen, giunto attualmente alla versione 3.3, si basa su un’architettura abbastanza semplice
L’hypervisor:
Il livello di astrazione più basso, lo XEN Hypervisor, ha due compiti principali:
1) astrarre l’hw sottostante
2) gestire le macchine virtuali operative nel sistema (poste ad un livello di astrazione superiore) in termini di:
• gestione della CPU;
• partizionamento della memoria; in pratica questo strato fornisce il processing enviroment necessario a ciascuna macchina virtuale, e non ha alcuna conoscenza delle reti a cui ciascuna macchina è connessa, o delle periferiche esterne utilizzate da una o più macchine virtuali.
La caratteristica più interessante di questo strato e la possibilità di paravirtualizzare l’hw sottostante. In pratica l’hypervisor è dotato di API che permettono allo stesso di presentarsi alle VM gestite come un sistema HW ad alte prestazioni; le VM paravirtualizzate quindi collaborano tra di loro e con l’hypervisor, che è dotato di API per il VM management, per minimizzare l’overhead legato alla virtualizzazione.
Le prestazioni offerte da questo strato SW sono elevate, ciò è dovuto a diversi fattori, tra i quali:
a) dimensioni dell’ hypervisor in termini di codice molto ridotte (inferiore a 50000 righe di codice);
b) Esecuzione nativa, direttamente sul processore, delle istruzioni richieste dai S.O. in esecuzione sulle VM, sfruttando le tecniche di virtualizzazione fornite dai processori Intel ed AMD.
Paragonata alle architetture di virtualizzazione basate su micro kernel, quella di XEN risulta essere dunque innovativa e performante.
Il Domain 0 e il Domain U:
Il Domain 0 può essere visto come una macchina virtuale, controllata dall’hypervisor, linux-based, che deve essere in esecuzione prima che venga caricata qualunque altra macchina virtuale. Questo perchè l’hypervisor si serve di questo S.O. per gestire le richieste di accesso alla rete e al disco pervenute dalle altre macchine virtuali. Il domain 0 è infatti fornito di due drivers, noti come il Network Driver ed il Block Driver.
Il S.O. residente su questa VM può essere:
– linux based kernel 2.4 o 2.6
– NetBSD 3.0
Le macchine virtuali effettivamente utilizzabili dall’utente appartengono invece al dominio U. Esse sono divise in due categorie:
1. Macchine virtuali Paravirtualizzate (PV guest): sono VM su cui sono in esecuzione, in modalità di paravirtualizzazione, versioni modificate dei S.O. Linux, Solaris e FreeBSD (e altri S.O. unix based). Queste macchine virtuali sanno che altre macchine virtuali sono in esecuzione sullo stesso sistema fisico e sanno di non accedere a una macchina reale, ma ad un livello sw di astrazione, che è l’hypervisor. Per questo motivo si parla di paravirtualizzazione e non di virtualizzazione effettiva. Ciascuna macchina virtuale PV contiene al suo interno i driver per l’accesso al disco e alla rete, così come accade per la VM del domain 0.
2. Macchine virtuali completamente virtualizzate (HPV guest): sono macchine virtuali su cui girano versioni standard dei S.O., quali Windows o Linux o altri S.O. Esse non sono a conoscenza dell’esistenza delle altre macchine virtuali, per cui per tali macchine la virtualizzazione è totale. Per questo motivo, appena una VM HPV viene lanciata, il S.O. su di essa residente deve essere supportato, nell’accesso al disco e alla rete, da un demone, denominato Qemu-dm, in esecuzione sul S.O. della VM del Domain 0, che intercetta e serve le richieste provenienti dal S.0. della VM HPV cui si riferisce; inoltre, ciascuna VM HPV è dotata di un sw per l’emulazione del firmware della macchina reale (ad esempio viene emulato il Bios del sistema, in modo tale che il S.O. possa eseguire il suo boot così come avviene su una macchina non virtuale). Questo ulteriore livello sw viene denominato Xen virtual firmware.
Completano l’architettura di XEN un insieme di demoni, residenti sul S.O. in esecuzione sul domain 0, divisi in demoni di gestione e di controllo delle VM in esecuzione. Tra essi vi sono:
– xend: system manager di XEN. Processa le richieste pervenute dal demone XM via RPC; utilizza la libreria libxenctrl per parlare con l’hypervisor
– xm: tool da riga di comando che riceve le richieste degli utenti e le invia a xend via RPC, sottoforma di file XML;
– xenstored: demone che mantiene aggiornato l’archivio delle comunicazioni tra la VM del domain 0 e le VMs del domain U.
Xen nella pratica
Esistono numerosi progetti di sviluppo e di ricerca che ruotano attorno a XEN. Molti di questi sono anche elencati sul portale dedicato all’ hypervisor nella sezione projects, raggiungibile all’indirizzo: http://www.xen.org/community/projects.html.
Tra questi uno dei più interessanti è sicuramente il progetto Xen Client Initiative (XCI), che ha come scopo quello di portare XEN su dispositivi meno usuali, come laptops e PDAs e telefoni; oppure il progetto Project Kemari, che sviluppa la sincronizzazione tra Virtual machines per introdurre tolleranza ai guasti nel sistema.
Tuttavia XEN non è solo ricerca e sviluppo, XEN è anche un prodotto commerciale;ad esempio si può vedere cosa propone Citrix, importante vendor che contribuisce allo sviluppo di XEN e contemporaneamente crea e distribuisce prodotti commerciali basati sull’hypervisor. Tra i vari prodotti, citiamo:
1. XENDesktop, software per la virtualizzazione low-cost, capace di creare desktop virtuali windows based, diretto competitor di VMWare;
2. XENServer, software di virtualizzazione per datacenter e server, disponibile in varie edizioni, a partire dalla Express Edition, una soluzione base scaricabile gratuitamente, fino ad arrivare alla più completa e sofisticata Enterprise Edition (chiamata in precedenza XenEnterprise).
Xen in Italia
Basta fare una ricerca in rete per trovare subito le risposte alla domanda. Ad esempio, la Cecchi Business Solutions di Prato propone un’implementazione di un sistema ridondante per la gestione di tutta l’infrastruttura della Server Farm interna di un ISP che sfrutta XEN. In particolare l’hypervisor è stato utilizzato per la gestione dello storage in quanto, grazie alla live relocation, consente di migrare le istanze dei S.O. in esecuzione su ogni VM da un sistema fisico ad un altro, in caso di guasto, in tempi molto ridotti.
Prestazioni e confronti
Quando si deve discutere sulle prestazioni e sui confronti, si tocca sempre un tasto dolente. Quello che emerge, confrontando XEN con il suo più diretto e temibile avversario, ossia VMvare, è che, a livello di numeri, i due competitors sono molto vicini; se si da ascolto ai benchmark rilasciati da chi sviluppa XEN, quest’ultimo sembra avere la meglio su VMware; accade l’opposto se si leggono i performances reports pubblicati dagli sviluppatori VMware. Stando all’ultimo whitepaper pubblicato da XEN, e approvato dagli sviluppatori di VMVare, sembrerebbe che XEN riesca a offrire prestazioni leggermente superiori, in media, rispetto a VMVare.
Per un’analisi più approfondita su questo punto, si rimanda alle analisi pubblicati da ciascuno dei due competitors, reperibili ai seguenti links:
http://www.vmware.com/pdf/hypervisor_performance.pdf
http://www.xensource.com/Documents/hypervisor_performance_comparison_1_0_5_with_esx-data.pdf
Da un punto di vista prettamente qualitativo, è possibile proporre un confronto tra i due hypervisors basato su tre direttive:
1) Implementazione architetturale: VMWare implementa quello che viene soprannominato il VMKernel, che ha un size di circa 200000 righe di codice pertanto ben superiore rispetto a quello dello strato hypervisor di XEN; ciò è dovuto alla scelta fatta da XEN di fornire uno strato software sottile, dotato di API per la virtualizzazione e la gestione della stessa, demandando tutte le funzionalità di sistema, al S.O. in running nella VM del domain 0.
2) Gestione della virtualizzazione: VMWare, pioniere della tecnica della binary translation, adatta le istruzioni da passare all’Hardware, provenienti dai S.O. attivi sulle VMs aperte, in modo tale che esse siano compatibili con l’ambiente di virtualizzazione; XEN, oltre a poter offrire questa tecnica, introduce la paravirtualizzazione, che sposta il livello di adattamento delle operazioni richieste al sistema dall’hypervisor al S.O. che le richiede; ciò ha il grande vantaggio di snellire l’hypervisor, evitando che esso debba “perdere tempo” a tradurre le operazioni richieste dai singoli S.O. al fine di renderle compatibili all’ambiente (virtuale), ma richiede di modificare i S.O. ospiti tramite apposite patches.
3) Utilizzo delle funzionalità di virtualizzazione Hardware based: ultimamente, tramite le tecnologie AMD-V e Intel-VT si è aperta la strada al supporto Hardware alla virtualizzazione. XEN offre la possibilità di utilizzare questi “hardware assists”, grazie ai quali è possibile anche su XEN lanciare su una VM aperta un S.O. non modificato; VMVare non offre supporto a queste tecniche, affermando che l’esperienza decennale nel settore ha portato ad un raffinamento della “trap and execute logic”, alla base della binary translation, tale per cui le prestazioni offerte da XEN con il supporto all’ hardware assist sono ancora (di poco) inferiori rispetto alle proprie. C’è da dire che, senza dubbio, con l’evoluzione del supporto hardware alla virtualizzazione, XEN riuscirà a offrire prestazioni superiori se VMWare non adotterà lo stesso tipo di supporto.
A cura di Antonio Savarese e Vincenzo Gargiulo
Vincenzo Gargiulo
Ingegnere informatico, svolge attività di Progettista in ENEL SERVIZI – ICT – Demand & Delivery Management Mercato – Area Gestione Clienti. Ha collaborato e collabora con l’Università Federico II di Napoli, Dipartimento di Informatica e Sistemistica, a progetti relativi a tematiche di dependability di sistemi SW ed HW. E’ esperto conoscitore di tematiche di ricerca legati alla crittografia e alla progettazione di SoC.
