1. INTRODUZIONE

I l concetto di virtualizzazione è da tempoampiamente utilizzato in vari settori della

computer science, dalla progettazione di si-stemi software complessi (esempio, sistemioperativi), ai linguaggi di programmazione, al-le architetture dei processori e alla trasmissio-ne dei dati. Da un punto di vista generale letecnologie di virtualizzazione puntano a di-saccoppiare il funzionamento logico delle ri-sorse hardware e software di un sistema dielaborazione dalla loro realizzazione fisica,con l’obiettivo di ottenere maggiore efficien-za, affidabilità e sicurezza. Il disaccoppiamen-to è ottenuto introducendo tra le due vistedella risorsa, la logica e la fisica, un livello diindirezione la cui realizzazione dipende dal ti-po di virtualizzazione che si intende adottare.Un primo esempio di virtualizzazione coinci-de con il concetto di astrazione. In questo ca-so l’obiettivo è semplificare l’uso di una ri-sorsa nascondendo alcuni aspetti di detta-glio relativi alla sua realizzazione. Si parla inquesto caso di risorsa virtuale (oggettoastratto) e il livello di indirezione introdotto è

costituito dalle operazioni (interfaccia) con lequali è possibile accedere alle risorse.Questo concetto di virtualizzazione vienenormalmente applicato nella progettazionedi sistemi di elaborazione complessi, chevengono organizzati come un insieme di li-velli di astrazione strutturati gerarchicamen-te [9]. Al livello più esterno le applicazioni di-spongono di una macchina virtuale il cui setdi istruzioni è composto dalle istruzioni nonprivilegiate della macchina fisica e da un in-sieme di nuove istruzioni rappresentate dallefunzioni fornite dal S.O. (system call), me-diante le quali è possibile accedere alle risor-se del sistema in modo semplice e sicuro.Il sistema di elaborazione è visto come un in-sieme di macchine virtuali, una per ogni pro-cesso attivo, che utilizzano tutte lo stesso li-vello di disaccoppiamento dalla macchina fi-sica rappresentato dall’interfaccia fornita dalS.O. Esse dipendono quindi dal S.O. di cuiutilizzano le system call e dall’hardware sulquale sono eseguite.Un caso diverso di macchina virtuale si pre-senta quando il livello di disaccoppiamento

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

Negli ultimi anni l’interesse per il settore delle tecnologie delle macchine vir-

tuali è cresciuto notevolmente. Si sono diffusi nuovi sistemi operativi per la

virtualizzazione e si stanno sviluppando progetti per rendere più semplice

ed efficiente il loro utilizzo. Un campo di applicazione interessante è la rior-

ganizzazione di server farm di grandi dimensioni per rendere più efficiente

l’uso delle risorse, semplificarne la gestione e aumentare la sicurezza.

Questo articolo descrive le proprietà delle tecnologie di virtualizzazione e

ne presenta l’utilizzo in un caso reale complesso.

Maurelio BoariSimone Balboni

TECNICHEDI VIRTUALIZZAZIONETEORIA E PRATICA

38

3.2

dalla macchina fisica è rappresentato dal co-dice generato da un compilatore di un lin-guaggio del tipo HLL. Tale codice, chiamatocodice astratto, risulta completamente indi-pendente dal set di istruzioni della macchinafisica e dalle system call del S.O. che in essaopera. Si parla in questo caso di macchinavirtuale a livello di linguaggio. L’obiettivo diquesta VM è permettere la portabilità dellostesso codice astratto su molteplici piattafor-me (hardware e S.O.) diverse. Ciascuna diqueste realizza una VM capace di caricare edeseguire il codice astratto e un insieme di li-brerie specifiche. Nella sua forma più sempli-ce, la VM contiene un interprete e, nei casipiù sofisticati, un compilatore, che partendodal codice astratto genera codice per la mac-china fisica sulla quale la VM è in esecuzione.Un esempio ben noto di tale paradigma è la Ja-va Virtual Machine (JVM) [6]. Lo sforzo di imple-mentare per le architetture più comuni una VMcapace di caricare ed eseguire il codice mac-china astratto è ben ripagato dalla piena por-tabilità del software attraverso le piattaforme.Un diverso utilizzo del concetto di virtualizza-zione, prevede l’introduzione di un livello diindirezione, che si chiama Virtual MachineMonitor (VMM) o hypervisor il cui compito èquello di trasformare la singola interfaccia dimacchina fisica in N interfacce virtuali. Cia-scuna di queste interfacce (macchine virtuali)è una replica della macchina fisica dotataquindi di tutte le istruzioni del processore(sia privilegiate che non privilegiate) e dellerisorse del sistema (memoria, dispositivi diI/O). Su ogni macchina virtuale può essereeseguito un sistema operativo. Compito delVMM è quindi consentire la condivisione daparte di più macchine virtuali di una singolapiattaforma hardware. Esso si pone comemediatore unico nelle interazioni tra le mac-chine virtuali e l’hardware sottostante, ga-rantendo un forte isolamento tra loro e la sta-bilità complessiva del sistema [5, 13].Un primo esempio di tale tipo di architetturaè quello introdotto da IBM negli anni ‘60 colsistema di elaborazione denominato origina-riamente CP/CMS e successivamenteVM/370 [8]. Il CP (Control Program) svolge lefunzioni del VMM, viene eseguito sulla mac-china fisica ed ha il solo compito di creare piùinterfacce della stessa, senza fornire alcun

servizio all’utente. Ciascuna di queste inter-facce (macchine virtuali) è una replica delsemplice hardware.Il CMS (Conversational Monitor System) è ilsistema operativo, interattivo e monoutente,che gira su ogni macchina virtuale.Il CP/CMS è nato dal lavoro svolto presso ilCentro Scientifico di IBM a Cambridge [3] ametà degli anni ‘60 con l’obiettivo di creareun sistema time-sharing. La sua adozione,nella versione VM/370, da parte di IBM fuuna diretta conseguenza del sostanziale falli-mento del sistema time-sharing TSS/360 co-struito per il modello 67 del 360 che si rivelònon adeguato alle aspettative perché troppocomplesso e poco efficiente.L’idea architetturale delle macchine virtuali,propria del nuovo sistema, consentiva ad ogniutente, tramite il CP, di avere la propria macchi-na virtuale con la propria partizione sul disco edi supportare lo sviluppo dei suoi programmiin tale macchina virtuale tramite il CMS.Tutta l’architettura risultava più semplice dagestire rispetto ad un tradizionale sistema ti-me-sharing in quanto risultavano separate, equindi sviluppabili indipendentemente, ledue parti di suddivisione dell’uso delle risor-se fisiche tra gli utenti e di mascheramentoper l’utente delle peculiarità dell’hardware.Inoltre, poiché ogni macchina virtuale erafunzionalmente identica all’hardware dellamacchina fisica, era possibile mettere inesecuzione su di esse qualunque sistemaoperativo compatibile con l’hardware stes-so e diverse macchine virtuali potevanoeseguire differenti sistemi operativi. Nelleversioni successive del VM/370 furonomessi in esecuzione sulle macchine virtualidiversi sistemi operativi, quali IBM OS/360e DOS/360. Un altro aspetto di interesseera l’elevata affidabilità del sistema dal mo-mento che la struttura del VMM consentival’esecuzione separata delle macchine vir-tuali garantendo quindi che un errore in unsistema operativo non avesse influenza sul-l’esecuzione degli altri S.O.La diffusione in quegli anni di questo tipo diarchitettura portò anche alla progettazionedi architetture hardware pensate per consen-tire in modo efficiente di soddisfare questeesigenze di virtualizzazione [19].A partire dagli anni ‘70 si sono diffusi i mo-

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

39

0

0

0

1

derni sistemi operativi multitasking e con-temporaneamente si è assistito ad un crollonel costo dell’hardware. I mainframe hannoprogressivamente lasciato il posto ai mini-computer e ad un paradigma del tipo “un ser-ver per ogni applicazione”, e così lo sviluppodei VMM si è interrotto al punto che le archi-tetture non hanno più fornito l’hardware ne-cessario per implementarli in modo efficien-te. Questa tendenza ha però portato nei pri-mi anni del 2000 ad una proliferazione del-l’hardware all’interno delle sale server, contanti minicomputer piuttosto sottoutilizzati,considerato il costante aumento della poten-za di calcolo, con grossi problemi legati aglispazi, al condizionamento degli ambienti,elevati costi di alimentazione e di gestione.Per questi motivi nella seconda metà deglianni ‘90 sono ricomparsi sul mercato nuoviVirtual Machine Monitor compatibili con l’ar-chitettura più diffusa entro le sale server, ov-vero IA-32, in un’ottica di consolidamento ditanti server sottoutilizzati su di un singolocalcolatore fisico. Questi sistemi sarannol’oggetto del prossimo paragrafo.Per concludere, si può ricordare che un casoparticolare di virtualizzazione si presentaquando si richiede l’esecuzione di program-mi compilati per un certo insieme di istruzio-ni su un sistema di elaborazione dotato di undiverso insieme di istruzioni. Si parla in que-sto caso di emulazione.

Il modo più diretto per emulare è interpreta-re: un programma interprete legge, decodifi-ca ed esegue ogni singola istruzione utiliz-zando il nuovo set di istruzioni. È un metodomolto generale e potente, ma produce un so-vraccarico mediamente molto elevato poichépossono essere necessarie decine di istru-zioni dell’host per interpretare una singolaistruzione sorgente.Una famosa implementazione, molto caraagli appassionati di giochi, è MAME [15], unaVM per host IA-32 in grado di caricare ed ese-guire il codice binario originale delle ROM deivideogiochi da bar degli anni ’80, emulandol’hardware tipico di quelle architetture. Fa-cendo leva sull’enorme potenza di calcolodegli attuali PC rispetto ai primordiali proces-sori per videogiochi dell’epoca, la VM puòtranquillamente operare secondo il paradig-ma dell’interpretazione senza compromette-re in modo significativo l’esperienza di gioco,almeno per i videogiochi più vecchi che nonfacevano ancora un uso massiccio della grafi-ca. Sono già oltre 1900 le immagini di ROMche si possono eseguire con MAME su di uncomune PC.Un ulteriore esempio è costituito dalla classedei microprocessori che, al fine di ridurre iconsumi energetici, implementano interna-mente un’architettura a parole molto lunghe(VLIW); all’esterno invece, grazie ad un emu-latore integrato in hardware, espongono unaclassica architettura IA-32, potendo così ese-guire i più noti sistemi operativi e relative ap-plicazioni. L’esempio più noto è il processoreTransmeta Crusoe [21], tra i cui progettisti vi èanche Linus Torvalds.

2. REALIZZAZIONE DEL VMM

Come si è visto nel paragrafo precedente,compito del VMM è consentire la condivisio-ne, da parte di più macchine virtuali, di unasingola piattaforma hardware. Il VMM espo-ne ad ogni macchina virtuale un insieme diinterfacce hardware funzionalmente equi-valenti a quelle di una macchina fisica e sipone come mediatore unico nelle interazio-ni tra le macchine virtuali e l’hardware sot-tostante, garantendo un forte isolamentotra esse e la stabilità complessiva del siste-ma (Figura 1).

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

0

0

0

1

40

FIGURA 1Schema logico di un ambiente virtualizzato: in questo esempio il VMM è postodirettamente sopra l’hardware, ed espone interfacce hardware virtualifunzionalmente identiche ad ognuna delle macchine virtuali in esecuzionesopra di esso

VM1

Applicazioni

Hardware

Applicazioni Applicazioni

Sistema operativo Sistema operativo

Virtual Machine Monitor

Sistema operativo

VM2 VM3

Al di là dei modi diversi in cui si può proget-tare un VMM, esso deve comunque soddi-sfare poche condizioni essenziali: fornire unambiente per i programmi sostanzialmenteidentico a quello della macchina reale; ga-rantire una elevata efficienza nella esecu-zione dei programmi; possedere caratteri-stiche di elevata semplicità. Il primo obietti-vo richiede che qualsiasi programma ese-guito all’interno di una macchina virtualegeneri lo stesso risultato che si otterrebbese il programma fosse eseguito direttamen-te sulla macchina reale. Le uniche differenzepossono essere legate alle dipendenze tem-porali imposte dalla presenza delle altremacchine virtuali concorrenti e dalla dispo-nibilità di risorse di sistema. Il secondoobiettivo, l’efficienza, richiede che l’o-verhead imposto dalla virtualizzazione siacomunque tale da offrire all’utente l’illusio-ne di operare sulla macchina reale. Per otte-nerlo occorre che un sottoinsieme statisti-camente dominante delle istruzioni del pro-cessore virtuale siano eseguite direttamen-te – senza la mediazione del VMM – sul pro-cessore reale. Questo approccio, noto comeesecuzione diretta, è centrale per potererealizzare efficacemente la virtualizzazione.In pratica esso prevede che le istruzioni nonprivilegiate, che sono la frazione più consi-stente di un instruction set, quelle da cuinon può derivare l’eventuale blocco del si-stema, siano eseguite direttamente inhardware senza coinvolgere in alcun modoil VMM. Quest’ultimo interviene invece solonell’esecuzione delle istruzioni privilegiate,minimizzando così il sovraccarico. Infine, ilrequisito della semplicità nella realizzazio-ne è essenziale per garantire la stabilità e lasicurezza dell’intero sistema, minimizzandol’occorrenza di malfunzionamenti che com-prometterebbero l’esistenza delle macchinevirtuali. In altre parole è necessario che ilVMM, nonostante la disponibilità delleistruzioni privilegiate per le macchine vir-tuali, resti sempre nel pieno controllo dellerisorse hardware e che non sia mai possibi-le ai programmi in esecuzione negli ambien-ti virtuali accedere all’hardware in modo pri-vilegiato scavalcando il controllo del VMM.Vi sono diversi modi per realizzare un VMMcon queste proprietà; le differenze fonda-

mentali tra le implementazioni più diffusesi possono ricondurre a due fattori discri-minanti: i principi che governano il dialogotra la macchina virtuale ed il VMM, ed il li-vello dove si intende collocare il VMM ri-spetto all’architettura del sistema di elabo-razione. Rispetto alla prima scelta, che è lapiù importante in termini di metodo, si di-stingue tra i paradigmi di virtualizzazionecompleta e paravirtualizzazione. Rispettoalla seconda scelta, si distingue tra VMMposti direttamente sopra l’hardware dell’e-laboratore (VMM di sistema) che integranoun sistema operativo “leggero” con le fun-zionalità di virtualizzazione e VMM che siistallano invece come applicazioni dentroun sistema operativo preesistente (VMMospitati). Normalmente viene indicato conil termine host la piattaforma di base sullaquale si realizzano macchine virtuali, checomprende la macchina fisica, l’eventualesistema operativo e il VMM; si indica invececon il termine guest tutto ciò (applicazionie sistema operativo) che ha a che fare conla macchina virtuale.Analizziamo ora i dettagli e le differenze dellediverse tecniche di realizzazione (Figura 2).a. Virtualizzazione completa. Il paradigmadella virtualizzazione completa prevede chel’hardware virtuale esposto dal VMM sia fun-zionalmente identico a quello della sotto-stante macchina fisica. In questo modo èpossibile installare dentro le macchine vir-tuali sistemi operativi standard, senza cheabbiano subito alcuna modifica specifica pereseguire in ambiente virtuale. Questo ap-proccio semplifica notevolmente la creazionee gestione dell’ambiente guest, ma rende unpo’ più complesso il disegno del VMM; inol-tre vedremo che per una efficace implemen-tazione è richiesta la collaborazione dell’ar-chitettura della CPU. Negli approfondimentiche seguono supponiamo, per semplicità,che il VMM sia installato direttamente sul-l’hardware del calcolatore.Un’architettura CPU in generale opera secon-do livelli (ring) di protezione: per semplicitàconsideriamo due soli livelli, supervisore edutente, anche se molte architetture, tra cui IA-32, implementano livelli intermedi usati adesempio per l'I/O. Il livello supervisore è riser-vato al software che deve accedere alle risor-

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

41

0

0

0

1

se del sistema con il massimo privilegio (siste-ma operativo, driver), e in tale stato si posso-no eseguire tutte le istruzioni proprie dell’ar-chitettura, tra cui anche le istruzioni privile-giate che danno pieno accesso alle risorsehardware e ai registri del sistema. Il livelloutente è riservato al software meno privilegia-to (applicazioni), e in tale stato non è possibi-le accedere alle istruzioni privilegiate dellaCPU. Se dallo stato utente si invocano istru-zioni privilegiate si attiva il meccanismo diprotezione della CPU che non esegue l’istru-zione in questione ma notifica allo stato su-pervisore, mediante una eccezione (trap), larichiesta ricevuta e gli passa il controllo. Nor-malmente, alcune delle componenti di un si-stema operativo (il kernel ed i driver) si aspet-tano di essere eseguite nello stato superviso-re, poiché devono controllare l’hardware. Inun contesto di virtualizzazione tuttavia, è so-lamente il VMM ad occupare lo stato supervi-sore, mentre tutti i software guest che vi gira-no sopra (applicazioni, ma anche sistemi ope-rativi) sono spinti più in alto, nel livello utente,con i privilegi di semplici applicazioni. Vi sonodunque due ordini di problemi nella gestionedi un sistema operativo guest che non si in-tende modificare ai fini della virtualizzazione:esso è chiamato ad operare in uno stato chenon gli è proprio, poichè le chiamate di acces-

so alle risorse gli sono inibite (problema diring deprivileging), inoltre esso è schiacciatonello stato utente insieme alle semplici appli-cazioni, con il problema di doversi proteggereda queste (problema di ring compression).Il VMM deve dunque mascherare ai sistemioperativi guest la natura dello stato in cui so-no eseguiti, facendosi carico di intercettareogni richiesta di accesso privilegiato al-l’hardware ed emulandone il comportamen-to. Si tratta infatti di richieste che non posso-no essere eseguite direttamente, ma nonpossono nemmeno essere ignorate pena ilmalfunzionamento o il blocco del sistemaguest, di cui si interromperebbe il normaleflusso operazionale. Per intercettare talichiamate il VMM è aiutato in modo determi-nante dalle funzionalità di protezione dell’ar-chitettura CPU: quando l’ambiente guesttenta di eseguire un’istruzione privilegiata, laCPU notifica un’eccezione al VMM (posto nel-lo stato supervisore) e gli trasferisce il con-trollo. Il VMM verifica la correttezza dell’ope-razione richiesta e provvede ad emularne ilcomportamento atteso. Se per esempio, unguest tenta di eseguire l’istruzione privilegia-ta che disabilita gli interrupt, il VMM riceve lanotifica di tale richiesta e ne emula il compor-tamento atteso, cioè sospende la consegnadegli interrupt solamente a quella macchina

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

0

0

0

1

42

FIGURA 2Confronto tra virtualizzazione completa (sinistra) e paravirtualizzazione (destra), su architetture IA-32. Un VMM per la virtualizzazionecompleta replica per ogni macchina virtuale le medesime interfacce hardware, funzionalmente identiche a quelle della sottostantemacchina fisica; per questo i sistemi operativi guest non devono essere modificati. Un VMM in paravirtualizzazione espone invece una APIcui i sistemi operativi guest devono interfacciarsi per accedere alle risorse

Applicazioni Applicazioni

Binary Translation

Applicazioni

Hardware Hardware

Applicazioni Applicazioni Applicazioni

VM1

VMM VMM

VM2 VM3 VM1 VM2 VM3

Sistema operativo Sistema operativo Sistema operativo Sistema operativomodificato

Sistema operativomodificato

Sistema operativomodificato

Hardware virtuale

Virtual Hardware API

virtuale. Così facendo, la macchina virtualeprosegue secondo il normale flusso opera-zionale che seguirebbe in un ambiente realeed il sistema rimane complessivamente sta-bile; se invece la richiesta della macchina vir-tuale fosse eseguita sul processore, sareb-bero disabilitati tutti gli interrupt per tutti i si-stemi e questo impedirebbe al VMM di rigua-dagnare il controllo della CPU.Il meccanismo di notifica della CPU aiuta amantenere piuttosto semplice il disegno delVMM, che in modo trasparente è chiamato adintervenire solamente per mediare l’accessoalle risorse hardware, di cui per altro mantie-ne sempre il controllo. La soluzione è ancheefficiente in quanto consente che tutte leistruzioni non privilegiate siano eseguite di-rettamente dall’hardware, senza alcuna su-pervisione da parte del VMM che non sarebbedi alcuna utilità ed introdurrebbe solo latenza.Un’architettura CPU si dice “naturalmentevirtualizzabile” se supporta l’invio di notificaallo stato supervisore per ogni istruzione pri-vilegiata eseguita dallo stato utente. Un’ar-chitettura di questo tipo favorisce un dise-gno semplice del VMM e supporta nativa-mente la tecnica dell’esecuzione diretta, fon-damentale per garantire prestazioni.È necessario osservare tuttavia che non tuttele architetture sono naturalmente virtualizza-bili e nel novero di queste vi è anche l’architet-tura IA-32, che pure oggi è al centro della rina-scita della virtualizzazione: realizzata nell’e-poca del boom del personal computer, non èstata affatto progettata tenendo presente lecondizioni per una semplice virtualizzazione.Alcune istruzioni privilegiate di questa archi-tettura se eseguite nello spazio utente nonprovocano un’interruzione da parte del mec-canismo di protezione della CPU ma vengonosemplicemente ignorate e non consentonoquindi un trasparente intervento del VMM.Inoltre, vi sono istruzioni non privilegiate,dunque consentite liberamente anche nellospazio utente, che permettono di accedere inlettura ad alcuni registri di sistema le cui infor-mazioni andrebbero però mascherate ad unamacchina virtuale e la cui gestione dovrebbeessere riservata solo al VMM (problema diring aliasing). Vi è per esempio un registro(code segment register) che segnala il livellodi privilegio corrente e la cui lettura da parte

di un sistema operativo guest – che come taleè eseguito nello spazio utente, che non gli sa-rebbe proprio – segnalerebbe al medesimoun’anomalia di collocazione.Questa assenza di supporto da parte del-l’hardware impone al VMM di implementarestratagemmi di varia natura per garantire ilfunzionamento della virtualizzazione comple-ta; i problemi possono essere risolti, ma alprezzo di un aumento di complessità ed unariduzione delle prestazioni. Una soluzione ti-pica prevede che il VMM scansioni il codiceprima di passarlo in esecuzione per impedireche blocchi contenenti queste istruzioni sianoeseguiti direttamente. VMware [8], per esem-pio, implementa la tecnica della fast binarytranslation [16] per sostituire i blocchi conte-nenti simili istruzioni problematiche in blocchiequivalenti dal punto di vista funzionale econtenenti istruzioni per la notifica di eccezio-ni che favoriscono l’intervento del VMM; taliblocchi equivalenti sono passati poi in esecu-zione diretta ed inoltre sono conservati in unacache apposita per riusi futuri, risparmiando ilcosto di ulteriori traslazioni. Questo processodi traslazione va applicato almeno all’interokernel del guest OS, per essere certi che tuttele istruzioni privilegiate che non notificano ec-cezioni vengano intercettate e gestite.b. Paravirtualizzazione. Il paradigma dellaparavirtualizzazione prevede che l’hardwa-re virtuale esposto dal VMM sia funzional-

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

43

0

0

0

1

Virtualizzazione completa e paravirtualizzazione

La virtualizzazione completa prevede che il VMM esponga ad ogni macchi-na virtuale interfacce hardware simulate funzionalmente identiche allecorrispondenti interfacce fisiche: in questo modo è possibile installaredentro le macchine virtuali sistemi operativi standard, senza che abbianosubito alcuna modifica specifica per eseguire in ambiente virtuale. All’in-terno della macchina virtuale, tutte le istruzioni non privilegiate sono ese-guite direttamente sul microprocessore del calcolatore (esecuzione diret-ta), ed il VMM si fa carico solamente di intercettare le richieste di accessoprivilegiato all’hardware e ne emula il comportamento atteso.La paravirtualizzazione prevede che il VMM esponga ad ogni macchina vir-tuale interfacce hardware simulate funzionalmente simili, ma non identi-che, alle corrispondenti interfacce fisiche: piuttosto che emulare le perife-riche hardware esistenti, il VMM espone una libreria di chiamate (VirtualHardware API) che implementa una semplice astrazione delle periferiche.Occorre dunque modificare il kernel ed i driver dei sistemi operativi guestper renderli compatibili con la virtual hardware API del VMM utilizzato. Lacomplicazione di dovere modificare i sistemi guest è però ripagata da unamaggiore semplicità del VMM, che non deve preoccuparsi di intercettarein modo complicato accessi alle risorse hardware, ma si avvale della lorodiretta collaborazione.

mente simile, ma non identico, a quello del-la sottostante macchina fisica. Piuttostoche emulare le periferiche hardware esi-stenti, il VMM espone una semplice astra-zione delle periferiche. In particolare, l’in-terfaccia hardware virtuale che il VMMespone ai sistemi guest è ridisegnata nellaforma di una Applications Programming In-terface (Virtual Hardware API), che i sistemiguest devono sapere richiamare per guada-gnare l’accesso alle risorse. Si richiede dun-que che i sistemi operativi guest non sianopiù tenuti all’oscuro, ma siano consapevolidi operare in un ambiente virtuale. Eviden-temente questo impone di modificarne ilkernel ed i driver per renderli compatibilicon le proprietà del VMM utilizzato; ma – edè la cosa più importante – non occorre asso-lutamente modificare le applicazioni che gi-rano sui sistemi operativi guest, perchè l’in-terfaccia tra le applicazioni ed il sistemaoperativo non viene toccata in alcun mododa questo approccio. Va dunque realizzatoun porting dei sistemi operativi esistenti,poiché gli attuali non sono scritti per dialo-gare con una API di paravirtualizzazione masolamente per gestire le interfacce hardwa-re standard. Questo è certamente un pro-blema, soprattutto per vecchi sistemi ope-rativi di tipo legacy. Di riflesso però risultaenormemente semplificata la struttura delVMM, poiché esso non deve più preoccu-parsi di individuare e catturare le operazioniprivilegiate dei guest OS per poi emularle,ma si avvale invece della loro diretta e con-sapevole collaborazione.Viene così meno il vincolo di operare con ar-chitetture CPU naturalmente virtualizzabili,non più essenziale per il funzionamento dellaparavirtualizzazione. Questo ha un impattoancor più notevole nel contesto delle archi-tetture IA-32 che non sono naturalmente vir-tualizzabili, e che – come poc’anzi visto – im-pongono al VMM l’implementazione di mec-canismi complicati per prevenire anomalie. Ilvantaggio maggiore di questo tipo di tecnica,rispetto alla precedente, consiste proprionella maggiore semplicità ed efficienza diesecuzione del VMM.Inoltre, vi sono contesti in cui la cooperazio-ne tra il VMM ed il sistema guest è necessa-ria per raggiungere un risultato efficace: per

esempio nell’ambito della gestione dellamemoria, si osserva che il VMM, come i tra-dizionali sistemi operativi, può fare uso del-la paginazione per spostare pagine di me-moria dalla memoria primaria al disco, con ilconsueto vantaggio di potere allocare piùmemoria di quella strettamente disponibile.Ciò è particolarmente importante nel conte-sto della virtualizzazione, con molti sistemie processi che insistono sulle stesse risorsesovra-allocate. Occorre dunque un meccani-smo efficiente che consenta al VMM di re-clamare ed ottenere in caso di necessitàdalle diverse macchine virtuali le porzioni dimemoria meno utilizzate. È chiaro che il si-stema operativo di ogni macchina virtualepossiede informazioni relative a quali sianole pagine di memoria più adatte ad esserespostate su disco, decisamente migliori diquelle del VMM. Per esempio, un guest OSpuò notare che una pagina di memoria ap-partiene ad un processo terminato e dun-que tale pagina non sarà più acceduta. IlVMM, operando al di fuori dei singoli guestOS, non può rendersi conto di questo e dun-que non sarebbe altrettanto efficiente neldecidere quali pagine di memoria trasferiresu disco per quella macchina. Una strategiacomunemente adoperata per risolvere que-sto problema è di tipo “paravirtualizzante”:su ogni macchina virtuale è in esecuzioneun processo, a volte detto balloon process(processo aerostato) che comunica con ilVMM. Quando vi è necessità di rastrellarememoria, il VMM chiede al balloon processdi allocare più memoria, cioè di “gonfiarsi”.Il guest OS, che meglio di tutti conosce l’uti-lizzo della memoria nell’ambito della mac-china virtuale, seleziona le pagine da offrireal balloon process per soddisfarne la richie-sta; il balloon process comunica tali pagineal VMM che ne rientra in possesso. La richie-sta del balloon process provoca da parte delguest OS il trasferimento su disco delle pa-gine probabilmente meno utilizzate dallamacchina virtuale, con l’effetto netto di ave-re liberato memoria a favore del VMM, cheprovvede alla riallocazione. Anche VMM cheper il resto operano secondo il paradigmadella virtualizzazione completa, come lostesso VMware, fanno largo uso di questimeccanismi tipici della paravirtualizzazio-

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

0

0

0

1

44

ne, in specifico nella gestione della memo-ria che – effettuata completamente dal difuori – sarebbe altrimenti molto complessae poco efficiente. In particolare, VMware of-fre l’opzione di installare dentro i sistemiguest un pacchetto di programmi (VMwareTools) in cui sono presenti questa e altre“sonde” per migliorare lo scambio di dati traVMM e guest.Nonostante la difficoltà di dovere realizzare ilporting dei sistemi operativi esistenti, la pa-ravirtualizzazione sta catalizzando un’atten-zione sempre crescente. Il progetto attual-mente più promettente di un VMM che operasecondo tale paradigma è XEN, un VMMopen source sviluppato dall’Università diCambridge [6]. Nell’ambito del progetto èstato realizzato il porting di Linux su XEN (Xe-noLinux), con un costo in termini di righe dicodice del Kernel modificato per dialogarecon la API del Virtual Hardware pari a circa3000 righe, cioè circa 1,36% del totale. Un la-voro analogo, in collaborazione con Micro-soft, è in corso per consentire il porting diWindows XP (XenoXP), ma il lavoro non è an-cora terminato e risulta essere più che altrouna sperimentazione. Attualmente lo svilup-po di XEN è alla versione 3; tra le funzionalitàpiù rilevanti vi è il supporto per sistemi multi-processore e per i più recenti kernel di Linux.Sono supportati inoltre meccanismi di “livemigration” di VM da un host con XEN ad unaltro: ciò permette di eseguire manutenzionisu di un singolo calcolatore senza interrom-pere i servizi, oppure bilanciare il carico com-plessivo tra i vari host con XEN di cui si dispo-ne. Inoltre le principali distribuzioni di Linuxcommerciali (Suse e RedHat) offrono già ipacchetti precompilati per installare XEN,nonchè le immagini della propria distribuzio-ne modificate per la paravirtualizzazione.XEN 3 supporta le istruzioni per la virtualiz-zazione che AMD ed Intel hanno di recenteinserito nei propri processori basati su IA-32e questo consente di eseguire sistemi guestWindows non modificati, in una modalità divirtualizzazione completa. In tal modo si so-no superati i problemi legati al porting di si-stemi guest proprietari. Sta infine crescendol’offerta di strumenti di lavoro che permetto-no una gestione centralizzata di varie instal-lazioni di XEN e delle relative macchine vir-

tuali, da un’unica console di controllo, in ana-logia al prodotto VirtualCenter venduto daVMware. Il progetto più rilevante in tale am-bito è Xensource, gestito dal gruppo storicoche coordina lo sviluppo di XEN. Si tratta diuna piattaforma commerciale per controllarepiù installazioni di XEN, con le relative mac-chine virtuali, da un’unica console centraliz-zata; grazie a questa piattaforma si possonocompiere le operazioni fondamentali di ge-stione come installare un nuovo sistema gue-st, monitorare l’utilizzo delle risorse, modifi-care la configurazione di un guest, accedernela console ecc..c. VMM di sistema e VMM ospitati. Soffer-miamoci su un’ultima distinzione rilevanteche caratterizza i sistemi di virtualizzazione:il livello dove si intende collocare il VMM ri-spetto all’architettura del sistema di elabora-zione. Abbiamo già accennato che si distin-gue in questo caso tra VMM posti diretta-mente sopra l’hardware dell’elaboratore(VMM di sistema) e VMM che si istallano in-vece come applicazioni dentro un sistemaoperativo preesistente (VMM ospitati) (Figu-ra 3). Nella prima opzione si integrano ad unsistema operativo “leggero” le funzionalitàdi virtualizzazione, in un unico sistema cheesegue direttamente sopra l’hardware dell’e-laboratore. Un’implementazione così a bas-so livello offre migliori prestazioni, anche sesi rende necessario corredare il VMM di tutti i

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

45

0

0

0

1

FIGURA 3Schema puramente indicativo di un VMM ospitato su di un sistema operativopreesistente, con cui condivide l’accesso alle risorse

VM1 VM2

Applicazioni

Applicazioni Applicazioni

Sistema operativo

Virtual Machine Monitor

Sistema operativo

Hardware

Sistema operativo

driver necessari per pilotare le periferiche. Ingenerale i prodotti implementati secondoquesto modello supportano un numero mol-to limitato di hardware certificato, rendendomeno impegnativa la gestione delle periferi-che altrimenti molto difficile vista l’enormevarietà degli hardware nel mercato consu-mer. Un esempio di VMM di sistema è peresempio la versione ESX di VMware, non acaso quella più diffusa in ambiti professiona-li, o anche lo stesso XEN. Quest’ultimo adot-ta driver derivati dal kernel di Linux ottimiz-zati per offrire le migliori prestazioni sull’I/Oin un contesto di virtualizzazione (varie VM inconcorrenza); naturalmente tali driver sonocompatibili con una lista molto ristretta dischede di rete e FibreChannel.La seconda opzione prevede invece l’installa-zione del VMM come un’applicazione sopraun sistema operativo preesistente e non diret-tamente sull’hardware del calcolatore. Con uncerto livello di approssimazione per non en-trare troppo nei dettagli, si può dire che ilVMM, anziché collocarsi sotto tutti gli altri li-velli software, opera nello spazio utente e ac-cede all’hardware attraverso le system callmesse a disposizione dal sistema operativosu cui si installa. Le performance sono certa-mente inferiori, ma ci sono alcuni vantaggi im-portanti: il VMM è più semplice da installarepoiché è come un’applicazione; inoltre potràfare affidamento sul sistema operativo sotto-stante - sicuramente più fornito di driver perl’hardware più diffuso – per la gestione delle

periferiche; infine, potrà servirsi di vari altriservizi dell’host OS come lo scheduling e lagestione delle risorse. È dunque una soluzio-ne comoda, che sacrifica le performance masemplifica il disegno del VMM ed è supportatada qualsiasi piattaforma IA-32 sulla quale siagià installabile un sistema operativo. Spessotale opzione è più che sufficiente per un uten-te che abbia solo l’esigenza di avere contem-poraneamente attivi sul proprio PC diversi si-stemi operativi per sviluppare o testare appli-cazioni. In questo segmento, per le architettu-re x86, si trovano la versione gratuita diVMware Server (prima noto come GSX), Vir-tual Server di Microsoft, il software opensour-ce User Mode Linux.

3. VIRTUALIZZAZIONEE CONSOLIDAMENTODEI SERVER ALL’UNIVERSITÀDI BOLOGNA

3.1. Il contestoL’Università di Bologna ha concentrato pres-so il proprio Centro Servizi Informatici d’Ate-neo (CeSIA) la gestione della rete accademicaALMAnet e della Server Farm che ospita i si-stemi per i servizi centralizzati: posta elettro-nica, DNS, file server, portale web d’Ateneo,sistemi per l’autenticazione, strumenti per ilmonitoraggio e la gestione della rete ALMA-net, le basi dati di personale e studenti, le ap-plicazioni per le segreterie, servizi per docen-ti, studenti, e per l’amministrazione generale.All’inizio del 2005 ci si è posti il problema delrinnovamento della Server Farm, che avevaraggiunto dimensioni critiche: 200 serverstand alone, Linux e Windows, ognuno con ilproprio disco in locale, ognuno dedicato inmodo esclusivo ad una singola applicazione oservizio, e come tale piuttosto sottoutilizzato.Un modello così rigido non era chiaramente inalcun modo scalabile e già così poneva grossiproblemi sui costi di approvvigionamento e dimanutenzione; vi erano inoltre problemi di or-dine logistico come il condizionamento del-l’ambiente e la distribuzione dell’energia elet-trica. Ma, soprattutto, si osservava che la solagestione ordinaria di un parco così ampio as-sorbiva completamente il personale prepo-sto, che vedeva ridursi il tempo per la partepiù qualificante del lavoro: lo sviluppo dei ser-

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

0

0

0

1

46

VMM di sistema e VMM ospitati

I VMM di sistema si installano direttamente sull’hardware del calcolatore,ed integrano le funzionalità di virtualizzazione ad un sistema operativo mi-nimale. Un’implementazione a basso livello offre migliori prestazioni, an-che se si rende necessario corredare il VMM di tutti i driver necessari perpilotare le periferiche. In generale i prodotti implementati secondo questomodello supportano un numero molto limitato di hardware certificato, ri-sultando compatibili con un piccolo sottoinsieme dell’hardware presentenel mercato consumer.I VMM ospitati si installano come un’applicazione all’interno di un sistemaoperativo preesistente e non direttamente sull’hardware del calcolatore. Conun certo livello di approssimazione si può dire che il VMM opera nello spazioutente e accede l’hardware attraverso le system call messe a disposizione dalsistema operativo su cui si installa. Le performance sono certamente inferio-ri, ma il VMM è più semplice da installare ed inoltre si affida al sistema opera-tivo sottostante - sicuramente più fornito di driver per l’hardware più diffuso –per la gestione delle periferiche. Esso potrà inoltre utilizzare servizi dell’hostOS come lo scheduling e la gestione delle risorse. È dunque una soluzionecomoda, che sacrifica le performance ma semplifica il disegno del VMM.

vizi a valore aggiunto che sono oggi conside-rati fondamentali, come la remotizzazione deidati, le politiche di recupero da disastro e dicontinuità operativa (Figura 4).Si è così stabilito di avviare un progetto di ra-zionalizzazione della Server Farm secondo li-nee più moderne, con l’obiettivo primario del-la diminuzione del mero lavoro gestionale edei costi di manutenzione, da attuarsi me-diante una riduzione del parco macchine econcentrando più servizi sui medesimi siste-mi (consolidamento hardware ed applicati-vo). Era poi richiesto che la nuova architetturasupportasse in modo semplice e nativo fun-zionalità di recupero da disastro e di conti-nuità operativa, da attuarsi con l’appoggio diun sito secondario a circa un chilometro di di-stanza dal CeSIA e connesso con esso tramitefibre ottiche, di cui l’Ateneo si era nel frattem-po dotato. Si richiedeva inoltre il supporto persistemi Windows e Linux, entrambi ampia-mente utilizzati in Ateneo e la possibilità disviluppare in modo più semplice, economicoe standardizzato i servizi intorno ai server, inparticolare backup/restore, monitoraggio, ri-dondanze.Sono state studiate le tecnologie per il con-solidamento ed acquisiti gli elementi di baseper realizzare un’architettura consolidata:hardware scalabili che consentono di dimen-sionare la potenza di elaborazione e lo spa-zio su disco in modo dinamico al cresceredella necessità, e sistemi operativi per la vir-tualizzazione, che consentono di partiziona-re le risorse hardware disponibili tra diversisistemi che ne fanno un uso concorrente.I calcolatori scelti sono quadriprocessori dual-core in architettura IA-32; essi accedono aisottosistemi disco attraverso la rete Fibre-Channel, una tecnologia di trasporto ottimiz-zata per la comunicazione dei comandi SCSI.Dei diversi VMM per architetture IA-32 è sta-to preferito VMware ESX per le seguenti ra-gioni: supporta sistemi operativi guest sia ditipo Windows che Linux; è dotato di una con-sole di gestione centralizzata (VirtualCenter)che permette di tenere sotto controllo edeseguire operazioni su tutte le macchine vir-tuali installate su qualsiasi calcolatore conVMware; dispone di meccanismi per la conti-nuità operativa (Vmotion) che permettono lamigrazione a caldo di una macchina virtuale

da un calcolatore con VMware ad un altro; di-spone di driver per la gestione del più diffusohardware professionale in commercio, confunzionalità avanzate per supportare la ri-dondanza dei percorsi di I/O; è dotato di unsistema molto raffinato di gestione della me-moria (risorsa scarsa e costosa) che consen-te una forte sovra-allocazione di memoria al-le VM rispetto alla memoria fisica presente.Va comunque osservato che le funzionalitàdescritte non sono in alcun modo prerogati-va del prodotto di VMware, ma con gradi disviluppo diversi sono caratteristiche comu-ni di quasi tutti i sistemi di virtualizzazionecommerciali ed opensource presenti sulmercato ([5, 6, 7, 12] e altri ancora). In parti-colare, ciò che ha permesso il cambiamentoradicale nel modello di gestione della Ser-ver Farm è stata la combinazione di hardwa-re scalabile di tipo “commodity” (cioè facil-mente reperibile sul mercato, e indifferente-mente da produttori diversi) unito al parti-zionamento delle risorse operato secondoprincipi molto simili da qualsiasi VMM perarchitetture IA-32. In particolare, è patrimo-nio comune di queste tecnologie operare ilmultiplexing delle risorse disponibili ed in-capsulare un intero server in un solo file su

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

47

0

0

0

1

FIGURA 4Modelli di gestione a confronto: rispetto ad un modello classico di gestione tipo“un server fisico per un’applicazione”, si evidenza la modularità dell’architetturanella nuova infrastruttura, la semplicità nell’estendere su siti comunicanti laServer Farm per ottenere continuità operativa, il ridotto numero di personenecessarie al presidio

Stato precedente Nuova atchitettura

Storage Area Network

CeSIA DR

IP

disco, azioni che sono la chiave di volta ditutte le funzionalità sopra descritte.

3.2. La soluzioneÈ nato così il nucleo della nuova Server Farm:in una tale architettura, una macchina virtua-le è un processo in esecuzione su di un calco-latore, ed il suo disco è interamente incapsu-lato in un file posizionato sullo Storage Array.Tutti i nuovi server sono stati sistematica-mente creati come VM all’interno di questainfrastruttura. I vecchi server sono stati mi-grati uno ad uno all’interno della nuova infra-struttura, alcuni ricostruendoli da zero in am-biente virtuale, altri trasferiti da fisico a vir-tuale mediante strumenti automatici che sioccupano di ricostruire in una VM un serverfisico ed il contenuto dei suoi dischi. Talisoftware sono spesso indicati come P2V, chesta per “Physical to Virtual”.Per supportare la continuità operativa, le retidi trasmissione dati sono state estese dal Ce-SIA verso il sito secondario mediante fibre ot-tiche di proprietà dell’Ateneo; nel sito secon-dario è stata predisposta un’uscita di backupverso Internet, e lì sono stati posti alcuni cal-colatori con VMware ed uno dei due StorageArray acquistati. Attraverso la rete FibreChan-nel, i calcolatori in un sito vedono anche il di-sco che è nell’altro sito: così le macchine vir-tuali in esecuzione al CeSIA possono esseremigrate a caldo – tramite Vmotion – anche suicalcolatori presenti nel sito secondario in po-chi secondi, consentendo ad esempio di effet-tuare manutenzioni su un singolo calcolatoresenza interrompere i servizi. Inoltre, in caso dirottura di un calcolatore nel sito primario i cal-colatori del sito secondario possono interve-nire riavviando i server caduti. Mediante mec-canismi di replica sincrona e asincrona dei da-ti attuati tra i controller dei due Storage Array,è possibile mantenere sul sito remoto una co-pia allineata in tempo reale dei dati più criticidel sito primario, per esempio le basi dati dipersonale e studenti. In modo analogo si puòmantenere nel sito secondario una copia delleimmagini disco delle macchine virtuali più im-portanti, per potere ripristinare i servizi nel si-to secondario anche nel caso di un disastroche paralizzi totalmente il CeSIA.Dopo un’attenta fase di test, si è compresoche era possibile concentrare fino a 40 VM

su di un unico quadriprocessore (8 core)con 32 GB di RAM. La vecchia sala server di200 macchine fisiche è stata così ristretta asoli 7 quadriprocessori, con risparmi ingentidal punto di vista dei costi di gestione. Leoperazioni quotidiane di presidio e gestioneordinaria si sono radicalmente semplificatepoiché l’intera Server Farm è diventata con-trollabile da un unica interfaccia – Virtual-Center – attraverso cui è possibile accederealle console dei server, monitorarne l’usodelle risorse, cambiarne a caldo la connetti-vità di rete, attivare allarmi al superamentodi soglie critiche, comandarne la migrazionea caldo nel caso occorra compiere manuten-zioni sull’hardware sottostante. È inoltre di-ventato semplice aggiornare l’hardware vir-tuale di una VM: si può incrementare la RAMo il numero di processori, aggiungere spa-zio disco o ulteriori schede di rete nello spa-zio di un riavvio.Un altro vantaggio fondamentale dell’am-biente virtuale è legato alla creazione di unnuovo server: si possono infatti confezionaredei template di installazioni tipiche (peresempio, una immagine di Windows 2003con a bordo antivirus, agente di backup e al-tre applicazioni già configurate) ed eseguireinstallazioni di nuovi server virtuali a partireda essi, con un notevole risparmio di tempoed energie. Si può anche creare un nuovoserver clonando una macchina virtuale già inesecuzione, ottenendo in modo molto rapidoun ambiente di test fedele all’originale perprovare ad esempio l’effetto di aggiornamen-ti di sistema, variazioni di configurazione etc.Inoltre, liberarsi di questi ambienti è facilecome cancellare un file: un vantaggio enor-

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

0

0

0

1

48

Virtual Appliance

Le Virtual Applicance sono macchine virtuali confe-zionate e configurate con a bordo tutto l’occorrenteper svolgere funzioni applicative di un certo tipo, co-me web server, firewall, applicazioni di fonia su IP,ecc.. Esistono in rete repositori che contengono cen-tinaia di immagini di Virtual Appliances divise percategorie e scaricabili gratuitamente. Ad oggi taliimmagini sono eseguibili esclusivamente sul VirtualMachine Monitor per cui sono state create, poichènon esistono standard condivisi per il formato deldisco delle VM o per le interfacce di paravirtualizza-zione. Sono comunque già molto utilizzate per te-stare e prototipare rapidamente ambienti operativi.

me rispetto all’approccio classico che impo-ne investimenti in acquisto di hardware dedi-cato, l’installazione del sistema operativo edelle applicazioni ecc. con pochissima flessi-bilità e costi elevati in termini di risorse uma-ne e materiali.La modularità dell’architettura, ad ogni suolivello, permette di acquisire autonomamen-te ed in stock le parti necessarie se le risorseper nuove VM scarseggiano: ulteriori calcola-tori per aumentare la capacità di elaborazio-ne, o ulteriori dischi per lo Storage Array. Sibeneficia così di una riduzione dei costi sia invirtù di acquisti in lotto, sia in virtù della ge-stione centralizzata dell’hardware e dellaelevata standardizzazione delle componenti.Dal punto di vista organizzativo poche per-sone, esperte sui temi della virtualizzazionedei sistemi operativi, dei sistemi di calcolo edisco, delle reti, sono in grado di governaresenza affanno un’architettura come quelladescritta, poiché la quota di lavoro mera-mente gestionale si riduce in modo notevo-le, e non scala in modo lineare con il nume-ro dei server.

Bibliografia

[1] Abramson, at al.: Intel Virtualization Techno-logy for directed I/O. Intel Technology Journal,Vol. 10, Issue 3, 2006.

[2] Adair R.J., Bayles R.U., Comeau L.W., CreasyR.J.: Virtual Machine for the 360/40. IBM Corp.,Cambridge Scientific Center, Report, n. 320-2007, May 1966.

[3] Adams K., Agesen O.: A Comparison of Softwa-re and Hardware Techniques for x86 Virtualiza-tion. ASPLOS’06 Conference Proceedings, Oc-tober 21–25, 2006, San Jose, California, USA.

[4] AMD Corporation: AMD64 Virtualization Codena-med “Pacifica” Technology: Secure Virtual Ma-chine. Architecture Reference Manual, May 2005.

[5] AA.VV.: User Mode Linux. 2006, http://user-mode-linux.sourceforge.net/

[6] Barham P., Dragovic B., Fraser K., Hand S., HarrisT., Ho A., Neugebauer R., Pratt I., Warfield A.: Xenand the Art of Virtualization. Proc. of the 19-thACM SIGOPS, October 2003.

[7] Bellard F.: QEMU opensource process emulator,2006. http://fabrice.bellard.free.fr/qemu/

[8] Creasy R.J.: The Origin of the VM/370 Time Sha-ring System. IBM J., Research and Develop-ment, Semptember 1981.

[9] Dijkstra E.W.: The Structure of the Multipro-gramming System. Communication of the ACM.Vol. 8, n. 9, 1968.

[10] Goldberg R.P.: Survey of Virtual Machines. Com-puter, June 1974.

[11] Goslin B., Steele G.: The Java Language Specifi-cation. Addison Wesley,1996.

[12] Microsoft Corporation: Microsoft Virtual Ser-ver 2005 R2 Technical Overview, 2005.http://www.microsoft.com/windowsserver-system/virtualserver/overview/vs2005te-ch.mspx

[13] Popek G.J, Goldberg R.P: Formal Requirementsfor Virtualizable Third Generation Architectu-res. Communication of the ACM, July 1974.

[14] Rosemblum M., Garfinkel T.: Virtual MachineMonitors: Current Technology and FutureTrends. IEEE Computer, May 2005.

[15] Salmoria N.: MAME, the Multiple Arcade Machi-ne Emulator. http://www.mame.net

[16] Sites R., et al.: Binary Translation. Comm. ACM,Febr. 1993.

[18] Sugerman J., Venkitachalam G., Beng-Hong Lim:Virtualizing I/O devices on VMware WorkstationHosted Virtual Machine Monitor. Proc.UsenixAnnual Technical Conference., June 2001.

[17] Smith J.E, Ravi Nair: The Architecture of VirtualMachines. IEEE Computer, May 2005.

[19] Uhlig C., Neiger G., et altri : Intel VirtualizationTecnology. IEEE Computer, May 2005.

[20] Waldspunger C.: Memory Resource manage-ment in VMware ESX Server. ACM SIGOPS Ope-rating Systems Rew, Winter 2002.

[21] Klaiber A.: The technology beyind Crusoe pro-cessors: low-power x86-compatible processorsimplemented with code morphing software. Te-ch. brief, Transmeta Corp., 2000.

SIMONE BALBONI è responsabile dei sistemi e servizi direte presso il Centro Servizi Informatici d’Ateneo del-l’Università di Bologna (CeSIA). Ha conseguito il dot-torato di ricerca in Fisica computazionale ed è autoredi alcuni articoli sul calcolo scientifico, sulle trasmis-sione in rete di dati multimediali, sulla sicurezzainformatica.E-mail: simone.balboni@unibo.it

MAURELIO BOARI è professore ordinario di calcolatorielettronici presso la Facoltà di Ingegneria dell'Uni-versità di Bologna. È autore di numerosi articoliscientifici ed alcuni libri. Ha interessi di ricerca nelsettore dei sistemi distribuiti, linguaggi di program-mazione e sistemi operativi. È attualmente delegatodel Rettore per l'informatica e le reti di Ateneo.E-mail: maurelio.boari@unibo.it

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1

49

0

0

0

1