Gestione di
Macchine Virtuali in
Ambiente Cloud
TR 1
Giuseppe CALARCO
Indice
1 Introduzione
6
2 Installazioni automatiche
8
2.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2
Windows Seven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.1
Answer File . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Installazione silenziosa di applicazioni . . . . . . . . . . . . . . . . . .
15
2.3
3 Cloud Computing
18
3.1
I diversi paradigmi di calcolo distribuito . . . . . . . . . . . . . . . .
19
3.2
Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3
Virtualizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.4
CLEVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.4.1
La comunicazione . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.4.2
La gestione dello storage . . . . . . . . . . . . . . . . . . . . .
27
1
INDICE
2
3.4.3
La virtualizzazione . . . . . . . . . . . . . . . . . . . . . . . .
4 La Virtualizzazione
29
32
4.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.2
Modalità di virtualizzazione . . . . . . . . . . . . . . . . . . . . . . .
34
4.3
Virtual Machine e Hypervisor . . . . . . . . . . . . . . . . . . . . . .
37
4.4
Tipologie di virtualizzazione dei sistemi . . . . . . . . . . . . . . . . .
41
4.4.1
Esempi di virtualizzatori . . . . . . . . . . . . . . . . . . . . .
49
Lo standard OVF . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.5.1
Virtual Appliance . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.5.2
Obiettivi di progettazione . . . . . . . . . . . . . . . . . . . .
55
4.5
5 Descrizione dell’implementazione
5.1
62
Agente CreateImage . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
5.1.1
CreateImage . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.1.2
Creazione del disco . . . . . . . . . . . . . . . . . . . . . . . .
69
5.2
Shell di amministrazione . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.3
OVF Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
5.3.1
OVF Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.3.2
Agente OVFCompute . . . . . . . . . . . . . . . . . . . . . . .
84
INDICE
3
6 Test sperimentali
86
6.1
Configurazione delle macchine . . . . . . . . . . . . . . . . . . . . . .
86
6.2
Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
7 Conclusioni e sviluppi futuri
91
Elenco delle figure
2.1
Confronto fra installazione automatica e manuale . . . . . . . . . . .
9
2.2
Interfaccia Windows SIM . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.1
Panoramica dei paradigmi di calcolo distribuito . . . . . . . . . . . .
20
3.2
Architettura Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3
Infrastruttura hardware per il middleware CLEVER . . . . . . . . . .
26
4.1
Virtualizzazione del sistema operativo . . . . . . . . . . . . . . . . . .
37
4.2
Tipo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.3
Tipo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.4
Livelli di protezione dell’architettura x86 . . . . . . . . . . . . . . . .
42
4.5
Virtualizzazione completa. . . . . . . . . . . . . . . . . . . . . . . . .
44
4.6
Hardware assisted virtualization. . . . . . . . . . . . . . . . . . . . .
45
4.7
Paravirtualization. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.8
Containers virtualization. . . . . . . . . . . . . . . . . . . . . . . . . .
47
4
ELENCO DELLE FIGURE
4.9
5
Hosted virtualization. . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.10 Virtual Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.1
Diagramma delle classi CreateImage
. . . . . . . . . . . . . . . . . .
65
5.2
Diagramma delle classi OVF . . . . . . . . . . . . . . . . . . . . . . .
80
5.3
Diagramma delle classi OVFComputeAgent . . . . . . . . . . . . . .
84
6.1
Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
Capitolo 1
Introduzione
Il lavoro di tesi si inserisce nell’ambito del cloud computing, che si sta diffondendo
notevolmente nel mondo IT e la cui diffusione è destinata a crescere in futuro. Per
questo si è determinata una rapida evoluzione ed un notevole incremento dei servizi
offerti disponibili su richiesta al singolo utente, il quale potrà gestirli come preferisce
indipendentemente dalla macchina che si trova ad utilizzare ed in qualunque parte
del mondo si trovi.
In tal senso l’Università degli Studi di Messina, in particolare la Facoltà di Ingegneria,
ha sviluppato un’architettura cloud open source, di nome CLEVER (CLoud-Enabled
Virtual EnviRonment) [17]. Essa ha il vantaggio di essere flessibile, scalabile, modulare e fault-tolerance, nonchè di utilizzare un approccio a plugin rendendo semplice
la modifica della struttura, l’integrazione di nuove tecnologie e l’aggiunta di nuove
funzionalità.
Il lavoro svolto nella presente tesi si è incentrato sul concetto di virtualizzazione in
6
CAPITOLO 1. INTRODUZIONE
7
CLEVER. Tale tecnologia, che fonda le sue radici nel passato, ormai gode di notevole diffusione grazie al fatto che garantisce numerosi benefici in termini di flessibilità,
scalabilità della struttura e notevole riduzione dei costi.
L’obiettivo considerato ha portato ad estendere le funzionalità del cloud, al fine di
poter permettere a ciascun utente di disporre di un proprio ambiente virtuale, realizzato secondo le sue esigenze. In questo modo, il generico fruitore dei servizi del
cloud potrà creare un disco immagine con il sistema operativo desiderato, al quale
sarà possibile accedere solo con un proprio account personale. Una volta creato il
disco, l’utente potrà creare ed avviare la macchina virtuale associata tramite delle
operazioni già implementate in CLEVER.
Un ulteriore sviluppo ha portato all’introduzione in CLEVER dello standard OVF
(Open Virtualization Format), che descrive un formato aperto, sicuro, portabile ed
efficiente per la distribuzione di macchine virtuali. Esso è indipendente dall’hypervisor utilizzato, non si basa sull’impiego di una piattaforma host specifica e per questo
è indipendente dalla piattaforma di virtualizzazione e dal sistema operativo guest.
Tali file OVF sono stati adattati secondo i requisiti richiesti ed è stato, quindi, implementato il parsing di questi file, utilizzando apposite librerie [20].
La prima parte del lavoro di tesi si incentra sullo studio di tecniche di installazione
automatica in ambienti Windows. A seguire vengono approfonditi i concetti relativi
al cloud computing e le sue relazioni con la virtualizzazione. Successivamente, viene
descritto lo standard OVF, come meccanismo di distribuzione di applicazioni virtuali,
fornendo infine una trattazione dettagliata dell’implementazione mediante l’uso del
linguaggio UML.
Capitolo 2
Installazioni automatiche
2.1
Introduzione
L’installazione automatica è una tecnologia utilizzata per l’installazione o l’aggiornamento di un sistema operativo con un intervento minimo o nullo da parte dell’utente,
ecco perché essa spesso viene definita unattended (non presidiata).
L’installazione automatica è meno conosciuta e meno usata rispetto a quella manuale.
Quest’ultima richiede l’avvio da CD-ROM, procedendo attraverso una serie di menu
che permettono di personalizzare determinate opzioni, di contro, quella automatica
richiede una fase di configurazione iniziale, necessaria a creare uno o più file di risposta (answer file).
Un file di risposta è un file di testo formattato in modo opportuno che indica al
programma di installazione le informazioni necessarie per installare e configurare il
sistema operativo.
8
CAPITOLO 2. INSTALLAZIONI AUTOMATICHE
9
Figura 2.1: Confronto fra installazione automatica e manuale
Un’installazione automatica, tipicamente, viene utilizzata in relazione a setup di larga
scala. Ad esempio, data un’istanza iniziale di un applicativo software o di un sistema
operativo da attivare su più siti, risulterebbe molto utile avvalersi di un’installazione
di tipo unattended.
L’installazione automatica arreca dunque numerosi vantaggi agli utenti, nonché agli
assemblatori, agli amministratori di sistema e, in generale, a chi debba configurare
un elevato numero di macchine in modo standardizzato.
CAPITOLO 2. INSTALLAZIONI AUTOMATICHE
10
Alcuni vantaggi sono i seguenti.
• si realizzano meno errori durante l’installazione. Mediante un’installazione automatica non vi è la minima interazione da parte degli amministratori e tecnici
durante il processo di installazione e questo riduce il numero di errori che si
presentano durante il processo di installazione.
• sussiste una maggiore coerenza nel corso di un setup di larga scala. Utilizzando lo stesso file di risposte per installare e configurare il sistema operativo, è
possibile garantire che tutti i computer di un’organizzazione siano impostati
esattamente nello stesso modo.
• si riducono i tempi di installazione. L’installazione automatica è più veloce rispetto a quella interattiva perché non è necessario attendere che gli amministratori o i tecnici inseriscano le informazioni di configurazione richieste; al programma di installazione, infatti, basterà leggere il file delle risposte precedentemente
settato.
• si determinano minori costi di supporto. Riducendo al minimo gli errori durante il processo di installazione, aumentando la coerenza dei computer di una
struttura, e riducendo il tempo necessario al setup, è possibile ridurre i costi
globali di sostegno all’interno di un’organizzazione aziendale.
Molti sono i sistemi operativi che permettono di eseguire delle installazioni automatiche, tra cui anche i sistemi Linux e Microsoft Windows, ed il principio di
funzionamento è piuttosto simile nei vari casi.
Di seguito si esaminerà l’installazione unattended di Windows Seven.
CAPITOLO 2. INSTALLAZIONI AUTOMATICHE
2.2
11
Windows Seven
A partire dal sistema operativo Windows Vista, il programma di installazione ha
subito notevoli cambiamenti che hanno reso le installazioni più veloci e più consistenti
rispetto a quelle di Windows XP. Si utilizza, infatti, l’Image Based Setup(IBS), una
nuova tecnologia basata sull’utilizzo di più file immagine in formato WIM (Windows
Imaging) con le seguenti proprietà:
• Memorizzazione di più immagini all’interno dello stesso file.
• Riduzione della dimensione del file immagine, utilizzando specifiche tecniche di
compressione.
• Personalizzazione del file immagine senza ricrearlo aggiungendo aggiornamenti
oppure drivers.
• File .wim sono bootabili.
• Installazione più semplice e veloce.
Per questo, l’immagine del sistema operativo è memorizzata in un unico file, install.wim, memorizzato all’interno della cartella sources. Vi è poi un ulteriore file
immagine, boot.wim, necessario per l’avviamento del programma di installazione.
Questa nuova tecnologia permette di poter installare, in base alla Product Key, diverse versioni del sistema operativo, come: Windows Seven Home premium,
Professional, Ultimate.
L’installazione di Windows Seven può essere divisa nelle seguenti fasi.
CAPITOLO 2. INSTALLAZIONI AUTOMATICHE
12
Preinstallation Phase
In questa fase viene configurata l’installazione del sistema operativo. Le attività
eseguite possono essere cosı̀ suddivise:
• Configurazione di Windows Setup: l’installazione viene configurata utilizzando le finestre di dialogo (interattiva) oppure il file di risposta (unattended ),
successivamente viene configurato il disco e le impostazione sulla lingua.
• Configurazione di Windows PE: vengono applicate le impostazioni lette nel
file di risposta.
• Configurazione del disco: l’hard disk viene formattato e partizionato per
l’installazione del sistema operativo.
• Copia dell’immagine di Windows: l’immagine del disco (install.wim) viene
copiata nel disco.
• Configurazione delle informazioni di boot: è possibile configurare sia
singolo che multi-boot.
• Configurazione dei servizi offline: vengono applicati gli aggiornamenti nell’immagine di Windows 7, tra cui correzioni software, language pack ed altri
aggiornamenti di sicurezza.
Online Configuration Phase
Durante questa fase, Windows 7 esegue attività di personalizzazione relative all’identità del computer, che rendono questa nuova installazione di Windows unica.
CAPITOLO 2. INSTALLAZIONI AUTOMATICHE
13
Windows Welcome Phase
Durante un’installazione manuale viene richiesto di scegliere un nome utente, il nome
del computer, uno sfondo del desktop e cosi via; mentre se è presente la sezione
oobeSystem nel file di risposta quest’ultima viene elaborata. Infine vi è l’esecuzione
della sezione Windows Welcome, che è conosciuta anche come Machine Out-Of-BoxExperience (OOBE), durante la quale si possono eseguire personalizzazioni finali,
come la creazione di account aggiuntivi.
2.2.1
Answer File
Il file di risposta di Windows Seven è un file XML (AutoUnattend.xml ), grazie al
quale è possibile automatizzare tutto o parte del processo di installazione. Esso può
essere creato mediante l’ausilio di Windows Automated Installation Kit (AIK), che
comprende un insieme di tool atti a realizzare immagini di Windows personalizzate. In
particolare l’utility che permette di creare il file di risposta prende il nome di Windows
SIM (System Image Manager). L’interfaccia grafica di Windows SIM presenta cinque
riquadri distinti:
• Distribution share. In cui è possibile inserire, ad esempio, eventuali driver
aggiuntivi da installare.
• Windows Image. In questo riquadro viene visualizzata l’immagine di Windows attualmente aperta (è necessario aprire un file .wim per creare un file di
risposta).
CAPITOLO 2. INSTALLAZIONI AUTOMATICHE
14
Figura 2.2: Interfaccia Windows SIM
• Answer file. In cui si crea o si modifica il file di risposta.
• Properties. Dove si consente di configurare i componenti e i pacchetti selezionati.
• Messages. Mostra errori, warning e messaggi informativi riguardanti la sintassi
del file creato.
Una volta aperto il file install.wim attraverso Windows SIM, è possibile creare il file
di risposta aggiungendo ai passi di configurazione i componenti desiderati.
I passi di configurazione sono suddivisi in:
• Windows PE. I componenti aggiunti a questo passo configurano la fase di
Windows PE.
CAPITOLO 2. INSTALLAZIONI AUTOMATICHE
15
• Offline servicing. Passo di configurazione utilizzabile per aggiungere dei driver
all’immagine di Windows.
• Specialize. Passaggio utilizzato dal sistema per configurare impostazioni specifiche di rete.
• AuditSystem. Si realizza il passaggio solo quando l’installazione avviene in modalità di controllo. Questa modalità è utilizzata per l’aggiunta di varie personalizzazioni a un’immagine di Windows e salta la fase finale di Windows Welcome
dell’installazione; in questo modo le configurazioni avvengono prima che l’utente
esegua il login.
• AuditUser. Passaggio simile al precedente ma eseguito solo dopo che l’utente
ha effettuato il login.
• OobeSystem. Corrisponde alla terza ed ultima fase del programma d’installazione.
2.3
Installazione silenziosa di applicazioni
L’installazione silenziosa è una modalità di installazione dei programmi in cui non c’è
interazione con l’utente, quindi non si realizza una visualizzazione di un’interfaccia
oppure di finestre di dialogo.
In questo modo, il programma si installerà con le impostazioni di default, cioè:
• accettazione automatica della licenza;
CAPITOLO 2. INSTALLAZIONI AUTOMATICHE
16
• creazione di scorciatoie;
• installazione dei tool aggiunti.
Per eseguire un’installazione silenziosa, basta eseguire il file di installazione con determinati parametri.
Il metodo classico per ricavare i parametri di installazione è quello di utilizzare il
comando “/?”.
La procedura però, non è delle più veloci e non sempre questo comando funziona.
Possiamo però utilizzare un comodo strumento (che si integra nel menù contestuale)
per la determinazione dei parametri di installazione silenziosa: CMenu. Una volta
scaricato ed installato, cliccate con il tasto destro del mouse, sul file di installazione
di cui volete conoscere i parametri di installazione silenziosa, scegliete dal menù contestuale “More Options” ⇒ “Installer Tools” ⇒ “Identify Installer”.
Tali parametri variano in base al “package installer”, dipendono cioè dal sistema
d’installazione utilizzato per la specifica applicazione. I parametri più comuni di installazione silenziosa sono “/s, /S, SILENT, silent, /qn”.
Le sintassi per lanciare l’installazione di un programma sono quindi: “setup.exe /s”,
“setup.exe /S”, “setup.exe /SILENT”.
I più comuni package installer sono:
• Inno Setup;
• Install Shield Installer;
• Nullsoft Scriptable Install System (NSIS);
CAPITOLO 2. INSTALLAZIONI AUTOMATICHE
• Windows Installer Service (MSI packages);
• Wise Installer.
17
Capitolo 3
Cloud Computing
Il Cloud Computing, secondo il National Institute of Standards and Technology
(NIST): è un modello per rendere possibile un accesso via rete, su richiesta e in
maniera conveniente, a un insieme condiviso di risorse configurabili (ad esempio reti,
server, storage, applicazioni e servizi) che possono essere rapidamente fornite e rilasciate con costi di gestione o interazioni con il fornitore minimali [8].
L’ambito è quello di calcolo distribuito e lo scenario è quindi quello di un utente che
con un qualsiasi device (PC, tablet, smartphone) ed una connessione ad Internet può
accedere al cloud che gli fornisce tutti i servizi e i dati richiesti [9]. È evidente cosı̀
come il Cloud Computing faccia in campo IT ciò che quotidianamente viene fatto
mediante la fornitura di elettricità, gas o altri tipi di servizi di uso comune. Tali
servizi vengono forniti all’utente su richiesta senza che debba preoccuparsi di come
siano forniti: l’utente chiede e il servizio viene fornito nella quantità desiderata. In un
modello di business cloud-based, il cliente, quindi, paga il provider in base al consumo
18
CAPITOLO 3. CLOUD COMPUTING
19
che effettivamente si verificherà. Il Cloud Computing offre, inoltre, a sviluppatori ed
utenti di applicazioni una visione astratta dei servizi che semplifica, ignorando molti
dei dettagli implementativi e dei funzionamenti interni dei servizi stessi [10].
3.1
I diversi paradigmi di calcolo distribuito
La definizione di Cloud Computing può essere comparata alle tecnologie esistenti,
come Grid Computing, Utility Computing, Service Computing, e calcolo distribuito
in generale.
In particolare, il Cloud Computing può essere considerato l’evoluzione del Grid Computing, da cui prende le mosse. L’evoluzione è la conseguenza di un cambiamento
di scenario che si è realizzato col passaggio da una tecnologia che fornisce storage e
grandi risorse di elaborazione (nel caso del Grid), ad una la cui economia è fondata
sull’erogazione di servizi e risorse più astratte.
Per quanto riguarda, invece, l’Utility Computing, esso non consiste in un nuovo paradigma di infrastruttura di calcolo, ma anzi consiste in un modello di business nel
quale le risorse di calcolo sono confezionate come servizi dosati, simili all’elettricità
ed alla rete telefonica.
L’Utility Computing è, tipicamente, implementato utilizzando altre infrastrutture di
calcolo, come le griglie, e aggiungendo dei servizi aggiuntivi di monitoraggio.
Un’infrastruttura cloud può essere invece utilizzata all’interno di una società oppure
esposta pubblicamente come Utility Computing.
La figura 3.1 ci mostra una panoramica del rapporto fra il Cloud Computing e gli
CAPITOLO 3. CLOUD COMPUTING
20
altri domini ai quali viene contrapposto. Il Web 2.0 copre quasi l’intero spettro di
applicazioni orientate ai servizi.
Figura 3.1: Panoramica dei paradigmi di calcolo distribuito
Supercomputing e Computing Cluster si basano sulle tradizionali applicazioni noservices. Il Grid Computing si sovrappone a tutti questi domini, però presenta una
minore scalabilità rispetto ai supercomputer ed ai clouds.
Il Grid Computing si propone di consentire la condivisione delle risorse e di problemsolving in organizzazioni virtuali dinamiche e multi-istituzionali [11]. Caratteristica
chiave di questo modello è rappresentata dal fatto che le griglie provvedono a fornire
un paradigma di calcolo distribuito che si estende su più organizzazioni virtuali (VO),
in cui ognuna di essa può essere costituita da istituzioni fisicamente distribuite o
progetti correlati logicamente. L’obiettivo di tale paradigma è quello di consentire
la condivisione delle risorse associate ad ambienti distribuiti dinamici. L’approccio
adottato come standard de facto [12], è quello di costruire un ambiente uniforme di
calcolo mediante la definizione di protocolli di rete standard, fornendo dei middleware
CAPITOLO 3. CLOUD COMPUTING
21
per mediare l’accesso a una vasta gamma di risorse eterogenee.
Secondo Ian Foster [13] una griglia deve coordinare risorse che non sono soggette a
controllo centralizzato, utilizzare protocolli ed interfacce standard, open e generalpurpose e offrire qualità di servizio non banali.
I punti di vista di cloud e grid sono molto simili, i dettagli e le tecnologie utilizzate
possono essere diverse, ma le due comunità sono alle prese con molti degli stessi
problemi.
3.2
Architettura
L’infrastruttura cloud consiste in un ampio pool di risorse di calcolo e di storage, a
cui è possibile accedere tramite protocolli standard attraverso un’interfaccia astratta.
Vi sono moltissime definizioni di architettura per i clouds, una di queste si basa su
quattro strati:
Figura 3.2: Architettura Cloud
CAPITOLO 3. CLOUD COMPUTING
22
• fabric che contiene le risorse grezze a livello hardware, come risorse di calcolo,
le risorse storage e di rete.
• unified resource che contiene le risorse astratte, incapsulate (di solito per
effetto della virtualizzazione), in modo che possano essere esposte allo strato
superiore, ad esempio, un computer virtuale, cluster, un database, ecc...
• platform che aggiunge una collezione di strumenti specializzati, middleware e
servizi per fornire una piattaforma di distribuzione.
• application che contiene le applicazioni che girano nel cloud.
I clouds, generalmente, possono fornire servizi che principalmente possono essere
ricondotti a tre tipi fondamentali [14]:
• SaaS (Software as service). E’ il livello più alto di servizi forniti. Attraverso
questa tecnologia è possibile avviare e utilizzare programmi in remoto. I clienti
non pagano per il possesso del software bensı̀ per l’utilizzo dello stesso. Essi
utilizzano il software tramite API accessibili via web, spesso come Web Services
o REST. Alcuni esempi di servizi SaaS sono un accesso webmail, un CRM e le
classiche “Google Apps”.
• PaaS. È l’acronimo di Platform as a Service, cioè la virtualizzazione di una
piattaforma. L’utente che utilizza tale servizio non deve occuparsi di gestire
l’infrastruttura sottostante, in quando questa operazione è stata già effettuata
dal fornitore del servizio. Ciò rappresenta anche una limitazione in quanto
CAPITOLO 3. CLOUD COMPUTING
23
l’utente per realizzare la propria applicazione dovrà necessariamente utilizzare
un’infrastruttura predefinita senza poterla adattare alle proprie esigenze.
• IaaS. È l’acronimo di Infrastructure as a Service ed è il servizio più vicino a ciò
che forma il cloud. Al cliente viene fornito un “computer virtuale” caratterizzato
da una certa quantità di ram, un certo numero di cpu, un’interfaccia di rete
e una certa quantità di storage. L’utente ha la possibilità di installare un
qualsiasi sistema operativo e di installare i programmi che preferisce. Inoltre,
ha a disposizione un “computer virtuale”, quindi non dovrà preoccuparsi di
eventuali guasti al sistema, in quanto vengono gestiti dal fornitore del servizio.
Generalmente tale servizio è tariffato ad ore di utilizzo, anche se esistono delle
soluzioni flat con fatturazione periodica. Un esempio è il servizio EC2/S3 fornito
da amazon.
3.3
Virtualizzazione
La virtualizzazione è la caratteristica che differenzia maggiormente il Cloud Computing dal precedente paradigma di calcolo distribuito Grid Computing.
Cosı̀ come i thread sono stati introdotti per fornire l’illusione, come se all’interno di
un computer fossero in esecuzione simultaneamente più attività, e ciascuna di esse
utilizzasse tutte le risorse disponibili, all’interno di un cloud è necessario eseguire
applicazioni per utenti multipli contemporaneamente ed in cui ciascuna di esse possa
utilizzare tutte le risorse disponibili.
La virtualizzazione consente che ogni applicazione sia incapsulata, in modo tale da
CAPITOLO 3. CLOUD COMPUTING
24
poterla configurare, distribuire, lanciare, migrare, sospendere, stoppare, ecc... Tutto
questo fornisce una migliore sicurezza, gestione ed isolamento.
Ci sono molti altri motivi per cui i cloud tendono ad adottare la virtualizzazione.
• Per esempio perché viene garantito il consolidamento dei server e delle applicazioni: più applicazioni possono essere eseguite sullo stesso server, più le risorse
possono essere utilizzate in modo efficiente.
• Si permette poi la configurazione, tramite cui le risorse necessarie per le varie
applicazioni potrebbero differire in modo significativo, dato che alcune di esse
potrebbero richiedere grandi dimensioni di memorizzazione, e altre maggiori
risorse di elaborazione. Al fine di configurare in modo dinamico e combinare
le risorse per le varie esigenze, è necessaria la virtualizzazione, perchè non è
realizzabile altrimenti a livello hardware.
• La virtualizzazione consente comunque una maggiore affidabilità, perché permette un recupero veloce da interruzioni non pianificate, e inoltre, gli ambienti
virtuali possono essere sottoposti a backup e migrazione senza interruzione del
servizio.
• Con il nuovo modello, poi, si determina maggiore reattività, in quanto possono
essere automatizzati sia provisioning delle risorse che monitoraggio e manutenzione, e le risorse comuni possono essere memorizzate all’interno della cache e
riutilizzate successivamente.
CAPITOLO 3. CLOUD COMPUTING
3.4
25
CLEVER
Il progetto CLEVER (Cloud Enabled Virtual EnviRonment) nasce con lo scopo di
creare un middleware distribuito per la gestione di un’infrastruttura di cloud computing e, allo stesso tempo, per consentire l’interconnessione con altri cloud al fine di
formare un cloud federato.
CLEVER è interamente sviluppato in linguaggio Java ed offre un’architettura altamente scalabile, modulare, tollerante ai guasti e flessibile; quest’ultimo requisito è
stato raggiunto integrando nella struttura di CLEVER il paradigma a plug-in, grazie
al quale è possibile modificare alcune parti del middleware o aggiungerne di nuove
senza mettere mani nel codice, bensı̀ modificando degli opportuni file di configurazione [17].
CLEVER è stato pensato per essere eseguito su un’infrastruttura hardware costituita
da un numero di nodi variabile e non necessariamente costante nel tempo, connessi
tra loro per mezzo di una rete internet.
Non è dunque strettamente necessario che i nodi fisici del cluster risiedano tutti sulla
stessa rete locale. A supporto di tale infrastruttura, come riportato in fig 3.3, è però
necessaria la presenza di un server XMPP, che rappresenta il cuore delle comunicazioni inter-modulo e di un database distribuito, su cui verranno salvati tutti i dati
necessari al corretto funzionamento e ripristino del middleware.
CLEVER è strutturato in maniera gerarchica e modulare, ed alla base troviamo dei
moduli denominati Host Manager, i cui compiti sono quelli di amministrare gli
ambienti virtuali sotto il loro controllo e collaborare con il sistema operativo dell’host sottostante per monitorarne le risorse fisiche. Sopra gli Host Manager troviamo
CAPITOLO 3. CLOUD COMPUTING
26
Figura 3.3: Infrastruttura hardware per il middleware CLEVER
un Cluster Manager, che ha una duplice funzione: monitora lo stato generale del
cluster, decidendo eventualmente la migrazione delle macchine virtuali da un host ad
un altro, in base alle condizioni di carico del cluster e si interfaccia con gli utenti ricevendo comandi, eseguendo le operazioni specificate e restituendo ai primi i risultati
relativi a tali operazioni.
I moduli Cluster Manager e Host Manager sono a loro volta costituiti da sotto-moduli,
rappresentati da un nucleo centrale, che coordina l’intero modulo, e dagli agenti, ciascuno dei quali è deputato a svolgere un compito ben preciso. Gli agenti a loro volta
implementano un plug-in, attraverso il quale possono eseguire le proprie operazioni.
Per il corretto funzionamento del middleware è necessario che su ogni host sia presente
CAPITOLO 3. CLOUD COMPUTING
27
un modulo Host Manager, e almeno un Cluster Manager per tutto il cluster. Tuttavia per aumentare la fault tollerance dell’architettura, saranno contemporaneamente
presenti, su host differenti, più Cluster Manager. Solo uno di questi svolgerà il ruolo
di coordinatore del cluster, gli altri serviranno da rimpiazzo nel caso quest’ultimo
andasse incontro ad un qualche errore che ne comporterebbe la terminazione.
3.4.1
La comunicazione
In Clever si distinguono principalmente due tipi di comunicazioni, quella interna e
quella esterna.
La comunicazione interna avviene all’interno dello stesso modulo, e viene sfruttato il
bus di sistema (D-Bus). Ogni agente infatti è un processo a sé stante, ed è quindi
possibile la comunicazione fra i vari agenti sfruttando il bus di sistema.
La comunicazione esterna è necessaria per lo scambio di messaggi fra il Cluster Manager e gli Host Manager; i moduli girano infatti su nodi differenti e non è quindi
possibile utilizzare il bus di sistema per la comunicazione. Per permettere la comunicazione inter-nodo si è scelta un’architettura client-server in cui tutti i nodi risultano
connessi attraverso la rete ad un server XMPP, che ha il compito di smistare i messaggi
verso il nodo corretto.
3.4.2
La gestione dello storage
Per la gestione dello storage ad alto livello [22], CLEVER utilizza una struttura ad
albero gerarchica, ovvero un catalogo logico in grado di gestire l’accesso ai file all’in-
CAPITOLO 3. CLOUD COMPUTING
28
terno del cluster. In tal senso, l’utente può decidere di caricare immediatamente un
dato all’interno del cluster, oppure in alternativa ha la facoltà di specificare un’ubicazione esterna, che può essere un server FTP o HTTP di sua proprietà. Il catalogo
logico rende CLEVER un unico File System Virtuale (VFS: Virtual File System), in
quanto fornisce un livello di astrazione che nasconde le differenze tra FS diversi.
L’albero che descrive tale catalogo virtuale prevede la presenza di tre tipi di nodi:
• Clever node che rappresenta un nodo virtuale che l’utente può creare in qualsiasi momento e che al suo interno può contenere altri nodi clever oppure nodi
link o nodi mount.
• Link node che rappresenta un collegamento ad un qualsiasi altro nodo logico
dell’albero. Si può fare un link anche ad uno specifico path fisico all’interno del
file system (mount node) in maniera del tutto trasparente. È un nodo foglia, il
che significa che non può avere nodi figli.
• Mount node che è un particolare nodo del file system nel quale sono effettivamente contenuti dei dati che è possibile esplorare. Anch’esso è un nodo foglia,
pertanto non è possibile creare dei sotto-nodi.
Fornendo un’analogia con i file system reali, i nodi clever rappresentano le directory,
mentre i nodi link ed i nodi mount sono i file che possono risiedere all’interno di tali
directory.
I nodi dell’albero possono avere lo stesso nome, ma devono essere raggiungibili da path
differenti, come accade in un normalissimo FS. I clever node ed i link node hanno
un significato logico più ad alto livello, mentre i nodi mount sono quelli che hanno
CAPITOLO 3. CLOUD COMPUTING
29
un significato fisico più a basso livello. L’utente, specificando un determinato path,
è in grado di eseguire l’attraversamento dell’albero in modo del tutto trasparente.
Tale path è costituito da due parti, il path logico che è il percorso dalla root ad un
qualsiasi nodo clever (clever node,link node, mount node ) e il path fisico che è il
percorso interno al file system. Giungere ad un nodo di tipo mount significa entrare
all’interno del FS e dunque, esplorarne il suo contenuto.
3.4.3
La virtualizzazione
Tutta la gestione delle macchine virtuali ad alto livello è affidata al componente Virtualization Manager presente nel modulo Cluster Manager.
Mediante la classe VirtualizationManagerClever vengono offerte molte funzionalità quali: registazione (register ), creazione (createVM ), avvio (startVm) ed arresto
(stopVm) di una VM.
La registrazione di un macchina virtuale consiste nella creazione da parte dell’utente
di un file XML, all’interno del quale vengono specificate tutte le caratteristiche della
VM.
L’intero meccanismo si fonda sulla classe VEDescription e sulle classi ad essa collegate. Per una maggiore trattazione sull’implementazione delle suddette classi si
rimanda il lettore al seguente lavoro di tesi [21]. In dettaglio, i parametri dell’ambiente virtuale (VE-Virtual Enviroment) sono visibili nel seguente codice XML:
<?xml version="1.0" encoding="UTF-8"?>
<org.clever.Common.VEInfo.VEDescription>
<os_guest_id>ubuntuGuest</os_guest_id>
CAPITOLO 3. CLOUD COMPUTING
30
<name>vvl</name>
<storage>
<org.clever.Common.VEInfo.StorageSettings>
<diskPath>peppecal/localftp/peppeXP_github.img</diskPath>
</org.clever.Common.VEInfo.StorageSettings>
</storage>
<cpu>
<numCpu>1</numCpu>
<coresXCpu>1</coresXCpu>
<frequency>0.0</frequency>
<architecture>X86_64</architecture>
</cpu>
<mem>
<size>512000</size>
</mem>
<network>
<org.clever.Common.VEInfo.NetworkSettings></org.clever.Common.VEInfo.NetworkSettings>
</network>
<desktop>
<username></username>
<password_user></password_user>
<password_vnc_vm></password_vnc_vm>
<ip_vnc></ip_vnc>
<port></port>
</desktop>
</org.clever.Common.VEInfo.VEDescription>
Ai fini dello storage, riveste un ruolo importante il tag diskPath in cui l’utente dovrà
specificare il percorso virtuale dell’immagine.
La creazione di una macchina virtuale consiste nel provvedere al recupero dell’immagine del disco, rendendola disponibile all’hypervisor. Si recupera l’oggetto VEDescription, lo si de-serializza e si estrae il diskPath relativo all’ubicazione dell’immagine della VM. Se le informazioni relative al nuovo ambiente virtuale sono corrette,
nel senso che non esiste già una VM con lo stesso nome oppure l’immagine del disco
è realmente presente nel path logico fornito, allora mediante il processo di creazione
CAPITOLO 3. CLOUD COMPUTING
31
viene copiato il disco all’interno del repository di Clever.
L’operazione di avvio provvederà al lancio della macchina virtuale appena registrata
e creata.
Capitolo 4
La Virtualizzazione
4.1
Introduzione
La virtualizzazione è espressione di un trend in evoluzione negli ultimi anni in ambito
informatico che comunque affonda le sue radici nel passato, come qualsiasi avvenimento legato alla tecnologia.
Si tratta di un sistema di tipo time-sharing che consente a più utenti di accedere allo
stesso computer e i suoi inizi si datano intorno agli anni ’60, quando in aziende, come
IBM per esempio, nasceva l’esigenza di consolidare i numerosi server, sparsi fisicamente, in un’unica macchina fisica, lasciando inalterate le caratteristiche principali
(indrizzo IP, servizi, ecc.) ma riducendo fortemente il consumo elettrico.
I sistemi di virtualizzazione non sono stati semplici da implementare. Inizialmente,
infatti, la maggior parte degli ingegneri aveva pensato di rendere i sistemi operativi
tradizionali maggiormente interattivi al fine di permettere a più utenti di entrare nello
32
CAPITOLO 4. LA VIRTUALIZZAZIONE
33
stesso sistema, ma in questo modo il sistema operativo stesso diventava estremamente
complesso. Un gruppo di ingegneri IBM di Cambridge, Mass., adottò poi un nuovo
approccio che permetteva a ciascun utente di accedere allo stesso sistema attraverso
una propria macchina virtuale (VM). In tal modo non si ravvisavano difficoltà nell’implementazione del sistema operativo perché doveva supportare un singolo utente.
Tecnicamente, con il termine virtualizzazione si intende la possibilità di astrarre le
componenti hardware degli elaboratori al fine di renderle disponibili al software in
forma di risorsa virtuale. L’insieme delle componenti hardware virtuali (Hard Disk,
RAM, CPU, NIC) prende il nome di macchina virtuale e su di esse possono essere
installati i software, come i sistemi operativi e le relative applicazioni.
I principali benefici derivati dall’avvento della virtualizzazione sono rappresentati:
• Scalabilità dell’infrastruttura, sia per un’eventuale richiesta di maggiore potenza di calcolo, sia per una richiesta di disponibilità di spazio per la
memorizzazione.
• Riduzione dei costi: la riduzione di server e delle relative risorse hardware
diminuisce le esigenze di spazio e le esigenze di alimentazione e raffreddamento.
Con l’ausilio di strumenti di gestione ottimizzati è possibile migliorare il rapporto server gestiti per amministratore e, di conseguenza, ridurre le esigenze di
personale.
• Migrazione: esecuzione di backup sicuri e migrazione di interi ambienti virtuali
senza interruzioni operative. Eliminazione dei downtime pianificati e ripristino
immediato in caso di imprevisti.
CAPITOLO 4. LA VIRTUALIZZAZIONE
34
• Sicurezza: possibilità di controllare e interrompere eventuali attività pericolose
in quanto tutte confinate nella virtual machine sotto il completo controllo del
sistema che ne governa l’esecuzione (hypervisor).
4.2
Modalità di virtualizzazione
Complessivamente, le aree di virtualizzazione sono quattro, a seconda che il processo
avvenga al livello delle applicazioni, di rete, del sistema di archiviazione o dei sistemi
operativi.
Virtualizzazione dei server di applicazioni
Questo tipo di virtualizzazione è nato con i primi servizi di bilanciamento del carico,
ragion per cui viene spesso definito virtualizzazione delle applicazioni. In effetti, gli
strumenti di bilanciamento del carico estendono il concetto di virtualizzazione del
server a un gruppo di server distribuiti tramite un proxy inverso, permettendo di
accedere a numerosi servizi applicativi in maniera trasparente tramite un’applicazione
o un servizio specifico.
In un normale deployment, un proxy inverso ospita un’interfaccia virtuale accessibile
per l’utente a livello front-end. A livello back-end, ovvero del sistema di produzione
interno che comprende i server critici dell’azienda, quali i server del data center o,
in certi casi, i server di applicazioni, il proxy inverso distribuisce il carico fra i vari
server e applicazioni, come ad esempio i server Web.
L’interfaccia virtuale, spesso denominata IP virtuale o VIP, diventa a questo punto
CAPITOLO 4. LA VIRTUALIZZAZIONE
35
il server Web effettivo, che gestisce le connessioni in entrata e in uscita a livello del
server a seconda delle esigenze. Questo permette al servizio di bilanciamento del
carico di gestire più applicazioni o server Web in modo centralizzato, come un’istanza
unica, offrendo una topologia più sicura e resistente rispetto a un’architettura con
accesso diretto a ogni server Web. Si tratta di un modello di virtualizzazione uno-amolti applicabile a qualsiasi tipo di architettura e deployment di applicazioni, in cui
un unico server rappresenta più server accessibili tramite un proxy inverso.
Virtualizzazione di rete
La virtualizzazione di rete consiste nella possibilità di riferirsi a risorse di rete senza
utilizzare la loro reale locazione fisica.
Un esempio può essere visto attraverso la VLAN (Virtual Local Area Networks).
Essa consiste in un gruppo di host che comunicano tra di loro come se fossero collegati
allo stesso cablaggio, a prescindere dalla loro posizione fisica. Le VLAN servono a
creare vari gruppi di lavoro nell’ambito di una LAN o MAN senza la necessità che
i componenti di un gruppo occupino spazi fisicamente contigui. I vantaggi che ne
derivano sono l’isolamento del traffico multicast e broadcast dei vari gruppi di lavoro
al livello Data Link e, di conseguenza, l’aumento della sicurezza del trasporto dei dati
e la diminuzione del carico di tutta la rete.
Un altro esempio è dato dalla VPN (Virtual Area Network). Essa è una tecnologia
che grazie all’utilizzo di internet od un’altra rete intermedia garantisce il collegamento
fra computer con reti di computer remote, altrimenti inaccessibili. La VPN offre
sicurezza, in quanto il traffico inviato attraverso la rete instaurata rimane isolato
CAPITOLO 4. LA VIRTUALIZZAZIONE
36
dagli altri computer presenti nella rete intermedia.
Virtualizzazione dei dispositivi di storage
La virtualizzazione del sistema di storage permette di rappresentare i dati indipendentemente dalla posizione e dalle caratteristiche dello storage, rendendo possibile un
miglior utilizzo delle risorse, un ripristino delle risorse più rapido e una semplificazione dei requisiti di spazio, energia e raffreddamento. Tuttavia, l’efficacia dei vantaggi
ottenibili con tale tecnologia dipende dalla completezza della soluzione di virtualizzazione del sistema di storage e dalla qualità della sua integrazione con l’architettura
per la gestione dei dati critici.
Virtualizzazione del sistema operativo
Oltre a rappresentare il tipo di virtualizzazione più diffuso, i sistemi operativi virtualizzati, o macchine virtuali, sono un componente indispensabile dell’infrastruttura IT,
che permette di eseguire sulla stessa piattaforma hardware più sistemi standard, fornendo agli utenti degli ambienti di esecuzione isolati e dedicati (Virtual Enviroment).
Si definiscono:
• Host machine: la macchina reale sulla quale viene effettuata la virtualizzazione.
• Guest machine: la macchina virtuale vera e propria che viene generata
Un Virtual Environment non è altro che un insieme di componenti hardware e periferiche implementate via software, conosciuto con il nome di Virtual Machine (Macchina
CAPITOLO 4. LA VIRTUALIZZAZIONE
37
Figura 4.1: Virtualizzazione del sistema operativo
Virtuale). La Virtual Machine permette l’esecuzione di un sistema operativo guest ed
una o più applicazioni che eseguono sopra di esso. Ogni Virtual Machine a sua volta
esegue sopra ad uno strato di virtualizzazione chiamato tecnicamente Hypervisor (Supervisore), il quale possiede un Virtual Machine Monitor (VMM). L’hypervisor è il
componente chiave che idealmente deve operare in maniera trasparente senza pesare
con la propria attività sul funzionamento e sulle prestazioni dei sistemi operativi.
4.3
Virtual Machine e Hypervisor
In dipendenza delle specifiche applicazioni, è possibile distinguere differenti classi di
Virtual Machine. Quelle maggiormente significative e utilizzate sono tre - sandbox,
emulation e native - e possono essere cosı̀ descritte:
• Sandbox - Macchine Virtuali di processo. Si fa riferimento ad un meccanismo
CAPITOLO 4. LA VIRTUALIZZAZIONE
38
di sicurezza per incapsulare programmi in esecuzione, fornendo un set di risorse
altamente controllato. Le macchine virtuali appartenenti a questa classe possono quindi essere utilizzate per l’esecuzione di codice non testato o programmi
non fidati, per restringere l’accesso a specifiche risorse per una data applicazione
o ancora per eseguire applicazioni sviluppate e compilate per specifici sistemi
operativi su altri sistemi.
In una sandbox, la memoria, il filesystem, la connessione di rete e in generale
tutte le risorse, sono rese accessibili tramite delle interfacce API fornite direttamente dalla sandbox stessa, la quale cosı̀ è in grado di monitorare e controllare
ogni tipo di accesso a tali risorse.
Esempi di sandbox largamente utilizzate al giorno d’oggi sono la Java Virtual
Machine [1], l’Adobe’s Flash Player o ancora l’antivirus Avast!
• Emulation - Macchine Virtuali di sistema Hosted. Queste macchine virtuali
emulano il completo funzionamento di un sistema operativo e con esse è possibile
pertanto eseguire sistemi operativi basati anche su architetture di processori
differenti.
Ne sono esempi QEMU [2] o Bochs [3].
• Native - Macchine Virtuali di sistema Nativo. Anche questa classe di macchine
virtuali, come la classe emulation, tenta di eseguire un sistema operativo guest
per intero. Essa sfrutta le caratteristiche di virtualizzazione proprie dell’hardware che utilizza, come le VT-X di Intel o le SVM di AMD, garantendo cosı̀
delle prestazioni migliori. Per esempio, considerando l’estensione di virtualizzazione di Intel VT-X 6, possono essere introdotte in particolare due transizioni:
CAPITOLO 4. LA VIRTUALIZZAZIONE
39
VMentry e VMExit, e, semplificando il discorso, si può verificare una VMentry
quando il controllo passa dal monitor VMM alla VM guest e analogamente si
verifica una VMexit quando il controllo passa dalla VM guest al VMM.
Esempi di VM di tipo native sono KVM [4] o VMware.
Il VMM, o hypervisor, viene definito come un software in esecuzione sulla macchina
reale che ha il completo controllo delle risorse hardware. Esso crea degli ambienti
d’esecuzione, detti macchine virtuali, che forniscono agli utenti l’illusione di un accesso
diretto alle risorse della macchina fisica.
Un VMM deve possedere le seguenti caratteristiche:
• Equivalenza: gli effetti dell’esecuzione di un programma attraverso il VMM
devono essere identici a quelli dello stesso programma eseguito direttamente
sulla macchina fisica, ad eccezione al più del tempo d’esecuzione dovuto all’overhead del VMM, alla ridotta disponibilità di risorse, che potrebbe fare andare in
swap il programma in esecuzione, ed ai dispositivi I/O agganciati, perché se la
VM non prevede periferiche collegate alla macchina reale (scheda di rete, USB,
scheda audio) potrebbe non poter accedere ad esse.
• Efficienza: l’ambiente virtuale deve essere efficiente. La maggior parte delle
istruzioni eseguite all’interno di tali ambienti deve essere eseguita direttamente
dal processore reale senza che il VMM intervenga. Le istruzioni che non possono
essere eseguite direttamente dal processore reale sono interpretate dal VMM.
• Controllo delle Risorse: il controllo delle risorse hardware deve essere di esclusiva competenza del VMM, senza interferenze da parte delle VM.
CAPITOLO 4. LA VIRTUALIZZAZIONE
40
L’hypervisor può essere suddiviso in tre generici moduli: dispatcher, allocator ed
interpreter. Il compito del dispatcher è di intercettare le istruzioni sensibili eseguite
dalle VM e passare il controllo ai moduli preposti a gestire tali operazioni. L’allocator
si preoccupa di fornire alle macchine virtuali le risorse necessarie evitando i conflitti.
Mentre l’interpreter si rende necessario in quanto le macchine virtuali non possono
avere accesso diretto alle risorse fisiche e non conoscono lo stato dell’hardware reale,
ma solo quello del loro ambiente virtuale. Le istruzioni che fanno riferimento alle
risorse vengono quindi simulate dall’interpreter.
Si possono individuare due tipologie di VMM [5] in base alla collocazione nell’ambiente
della macchina fisica:
• Il VMM di tipo 1 è posto immediatamente sopra l’hardware e dispone di tutti
i meccanismi di un normale kernel per quello che riguarda la gestione delle
memoria, delle periferiche e del processore.
Figura 4.2: Tipo 1
CAPITOLO 4. LA VIRTUALIZZAZIONE
41
• Il VMM di tipo 2 è un normale processo in esecuzione nell’ambito del sistema
operativo host. Gestisce direttamente le macchine virtuali, che sono suoi sottoprocessi, mentre la gestione hardware è demandata al sistema ospitante. In virtù
di quanto detto la sua implementazione dovrebbe essere più semplice rispetto
al VMM di tipo 1.
Figura 4.3: Tipo 2
4.4
Tipologie di virtualizzazione dei sistemi
Un concetto importante riguarda i livelli di protezione dell’architettura x86 (ring
level ). Il livello 0 ha i privilegi più alti e, normalmente, in esso vi è il sistema operativo. Il codice eseguito in questo livello può essere in esecuzione in modalità: system
space, kernel mode oppure supervisor mode. Qualsiasi altro tipo di codice, come
CAPITOLO 4. LA VIRTUALIZZAZIONE
42
le applicazioni del sistema operativo, operano in livelli meno privilegiati (livello 3).
L’hypervisor viene eseguito direttamente nell’hardware del sistema host nel ring 0.
Figura 4.4: Livelli di protezione dell’architettura x86
Esso gestisce le richieste hardware per conto del sistema operativo guest. Esistono
comunque scenari dove alcune operazioni non possono essere eseguite dal sistema operativo guest se non ha diretto contatto con l’hardware. Per questo motivo l’hypervisor
deve implementare una metodologia per intrappolare queste richieste di operazioni
delicate e trasformarle in operazioni eseguibili correttamente, il tutto operando in
maniera dinamica. Tale obiettivo è raggiungibile mediante diversi approcci [6].
Full Virtualization
Essa consente l’esecuzione di sistemi operativi non modificati (o non modificabili per
ragioni di licenza) in un ambiente totalmente ricreato ed isolato dal sistema operativo
che lo ospita; tale ambiente è realizzato da un apposito software che si occupa di
emulare l’hardware necessario traducendo le istruzioni eseguite dal sistema ospite in
CAPITOLO 4. LA VIRTUALIZZAZIONE
43
qualcosa che il sistema operativo ospitante sia in grado di eseguire. Come è possibile
intuire, la traduzione di ogni singola istruzione è molto onerosa a livello di potenza
di calcolo, per ovviare a ciò è necessario eseguire la maggior parte delle istruzioni in
modo nativo.
Sebbene quindi esistano emulatori di CPU differenti dall’architettura x86, come ad
esempio Qemu che è in grado di emulare ARM, Alpha, MIPS, SPARC o Hercules
che emula System/370, ESA/390 e z/Architecture, questi emulatori tendono ad essere
molto lenti poiché devono tradurre ogni istruzione verso l’architettura x86, eseguirla,
e quindi tradurne il risultato verso l’architettura emulata.
Imponendo quindi un limite sull’architettura virtualizzata (x86 virtualizza solo x86),
è possibile velocizzare notevolmente l’esecuzione dei sistemi guest mappando direttamente memoria e CPU (per quanto riguarda le istruzioni accessibili). Questo limite
rende però impossibile virtualizzare sistemi x86 64 se il sistema operativo di base è
i386 (come nel caso di VMWare ESX). Questo succede perché l’architettura i386
prevede l’esecuzione di codice in due modalità:
• Real Mode: dove ogni processo ha completo accesso a tutto l’hardware (tale
modalità è quantomeno rischiosa e preclude il concetto di virtualizzazione);
• Protected Mode: vengono creati diversi livelli di protezione che possono essere
immaginati come anelli (RING) concentrici sempre più restrittivi man mano che
si procede verso l’esterno.
CAPITOLO 4. LA VIRTUALIZZAZIONE
44
Figura 4.5: Virtualizzazione completa.
Hardware Assisted Virtualization
Conosciuta anche come Accelerated Virtualization oppure con nomi diversi a seconda del produttore, ad esempio Xen la chiama Hardware Virtual Machine (HVM),
Virtual Iron la chiama Native Virtualization. Questa tecnica si appoggia a speciali funzioni della CPU (Intel VT e AMD-V) e permette l’esecuzione direttamente in
hardware di alcune chiamate della macchina virtuale. La più importante conseguenza
di questo supporto in hardware è il superamento del limite della Full Virtualization:
grazie a queste estensioni è infatti possibile avere come guest sistemi x86 64 nonostante il sistema ospitante sia i386. Occorre precisare che l’attuale virtualizzazione
assistita si occupa di aiutare solamente funzioni di CPU e memoria; tutte le funzionalità di I/O sono ancora emulate. Esistono già delle specifiche per permettere a diverse
istanze virtuali di condividere schede PCI Express.
Vengono introdotte due nuove modalità operative, trasversali ai livelli di protezione
dell’architettura (ring level): la modalità Root e la modalità non Root. Sia i guest che
CAPITOLO 4. LA VIRTUALIZZAZIONE
45
gli host potranno operare sempre al giusto ring-level (generalmente 0 in kernel-mode,
3 in user-mode), ma solo il VMM potrà accedere alla modalità Root, che fornisce
l’accesso a tutte le funzionalità di gestione della virtualizzazione implementate dalle
estensioni.
Figura 4.6: Hardware assisted virtualization.
CAPITOLO 4. LA VIRTUALIZZAZIONE
46
ParaVirtualization
Essa è una tecnica in cui il sistema operativo virtualizzato riesce a comunicare direttamente con il Motore di Virtualizzazione (hypervisor). Questo comporta la necessità
di modificare il kernel del sistema operativo da virtualizzare risultando problematico
nel caso di prodotti come Windows che, per motivi di licenza, non permettono la
modifica del codice.
Xen, ad esempio, permette l’installazione di sistemi operativi Linux con kernel modificato e driver personalizzati. Il vantaggio nell’usare la ParaVirtualization consiste
nella maggior velocità di esecuzione delle applicazioni utente. Xen e Microsoft
Virtual Server sono esempi di software che utilizzano ParaVirtualization.
Figura 4.7: Paravirtualization.
CAPITOLO 4. LA VIRTUALIZZAZIONE
47
Containers
Questa tipologia di Virtualizzazione è ancora più slegata dall’hardware fisico e più
legata al sistema operativo stesso. Containers prevede che sia in esecuzione un solo
kernel unico che crea diverse istanze in user space; in questo modo si ha un bassissimo
overhead, ma anche un bassissimo isolamento: un kernel panic sarebbe fatale per tutti
i sistemi contenuti nello stesso hardware. Una ovvia conseguenza è che avendo un
unico kernel, i sistemi operativi ospitati avranno ovviamente la stessa versione di
kernel. Semplificando al massimo, questa tecnologia si avvicina molto al concetto di
chroot.
Figura 4.8: Containers virtualization.
CAPITOLO 4. LA VIRTUALIZZAZIONE
48
Hosted
L’ultima tipologia di virtualizzazione forse è più familiare all’utente rispetto le altre.
Tutti i prodotti desktop di virtualizzazione, come VMware Workstation, VMware
Fusion, Parallels Desktop per Mac, e Microsoft Virtual PC implementano una virtualizzazione di tipo hosted. Gli utenti possono installare un prodotto di virtualizzazione
sul proprio pc come qualsiasi altra applicazione, e continuare a usare il loro sistema
operativo desktop.
Figura 4.9: Hosted virtualization.
CAPITOLO 4. LA VIRTUALIZZAZIONE
4.4.1
49
Esempi di virtualizzatori
Di seguito vengono trattati alcuni tipi di virtualizzatori.
Qemu
Qemu, acronimo di Quick EMUlator, è un software che implementa un particolare
sistema di emulazione che permette di ottenere un’architettura nuova e disgiunta in
un’altra che si occuperà di ospitarla.
Esso ha due modi di operare:
• Full system emulation. In questo caso Qemu emula l’intero sistema, incluso il
processore e le periferiche. Può essere utilizzato per lanciare differenti sistemi
operativi senza il riavvio del PC.
• User mode emulation (solo per Linux). Qemu può essere lanciato come processo
Linux compilato per una CPU o per un’altra.
KVM
Kernel-based Virtual Machine è un sistema full-virtualization esclusivamente per
GNU Linux, su piattaforma x86, che può essere facilmente installato su qualsiasi distribuzione, l’unico prerequisito è possedere un processore con istruzioni Intel-VT o
AMD-V.
Esso consiste in un modulo kernel (kvm.ko) che fornisce la virtualizzazione dell’infrastruttura di base ed un modulo specifico per il processore in uso (kvm-intel.ko o
CAPITOLO 4. LA VIRTUALIZZAZIONE
50
kvm-amd.ko) a seconda dei casi.
KVM presenta un approccio diverso rispetto ad altri sistemi di virtualizzazione professionale. Esso non prevede infatti l’utilizzo di un hypervisor a se stante, ma utilizza
il kernel Linux a questo scopo, questa è una scelta strategica decisiva che porta numerosi vantaggi. Uno tra tutti è il fatto che grazie a questo, il team di sviluppo di KVM,
non deve preoccuparsi di scrivere da sé driver per le periferiche o tool di gestione,
tutto ciò è offerto dal kernel Linux.
L’integrazione di KVM con il kernel è cosı̀ profonda, che le virtual machine sono nel
sistema dei semplici processi. Il fatto che le singole virtual machine vengano viste
dal sistema come semplici processi, consente al kernel di trattarli come tali e questo
ne aumenta notevolmente la facilità di gestione. Grazie a ciò infatti la macchina che
ospita la VM, se dotata di hardware sufciente, risulta sempre uida e dimostra buona
velocità di risposta, anche quando il sistema ospitato è sotto sforzo.
VirtualBox
VirtualBox è una piattaforma di virtualizzazione prodotta da Sun Microsystems, che
abilita una full virtualization. Supporta Windows, Mac, Linux e Solaris come sistemi
operativi host e permette l’esecuzione di ambienti virtuali a sistemi di ogni tipo, sia
x86 che x86 64.
VirtualBox ha un’architettura modulare con interfacce di programmazione interne
ben definite e una chiara divisione tra codice client e server. Questo rende possibile
controllare agevolmente una macchina virtuale tramite diverse interfacce: ad esempio,
è possibile creare una macchina virtuale tramite l’interfaccia grafica per poi control-
CAPITOLO 4. LA VIRTUALIZZAZIONE
51
larla da riga di comando.
VirtualBox funziona allo stesso modo su tutte le piattaforme e le macchine virtuali
possono essere facilmente importate ed esportate utilizzando lo standard OVF (Open
Virtualization Format).
Per quanto riguarda lo storage virtuale, viene utizzato un file immagine sul disco
fisico ed esso sarà presentato al sistema guest come hard disk virtuale. Quando il sistema operativo guest effettua operazioni di lettura o scrittura su disco, l’hypervisor
di VirtualBox redireziona la richiesta verso questo file. I formati del file supportati
sono VDI, VMDK, VHD ed HDD.
Oltre all’interfaccia grafica, VirtualBox presenta diversi front-end:
• VBoxManage; è la CLI di Virtualbox e fornisce funzionalità avanzate non
accessibili tramite l’interfaccia grafica.
• VBoxSDL; è un’interfaccia grafica con un insieme limitato di funzioni, designata
per visualizzare macchine virtuali controllate con VBoxManage.
• VBoxHeadless; non fornisce nessun tipo di output sull’host e agisce unicamente
da server RDP.
Inoltre, VirtualBox permette di attivare un server RDP, che prende il nome di VRDP
(VirtualBox RDP), grazie al quale è possibile visualizzare e controllare una macchina
virtuale in remoto attraverso un client RDP standard. Di default il server VRDP
utilizza la porta TCP standard di RDP (3389).
CAPITOLO 4. LA VIRTUALIZZAZIONE
4.5
52
Lo standard OVF
La rapida adozione delle infrastrutture virtuali ha messo in luce la necessità di un
modello standard e portabile per la distribuzione di macchine virtuali fra le diverse
piattaforme di virtualizzazione.
La creazione di un’applicazione con un determinato sistema operativo nel quale è
certificato che essa possa essere trasferita fra differenti ISV(Indipendent Software
Vendor) come un’unità pre-configurata, risulta essere molto vantaggioso ed allettante. Si tratta di applicazioni che possono essere lanciate attraverso macchine virtuali
e sono chiamate Virtual Appliance.
Al fine di sviluppare il concetto in larga scala è importante che i produttori adottino
uno standard neutrale per il confezionamento delle macchine virtuali ed utilizzino dei
meta-dati necessari per un’installazione automatica e sicura, nonché per la configurazione ed il lancio della Virtual Appliance in qualsiasi piattaforma di virtualizzazione.
Le Virtual Appliance hanno cambiato il paradigma di distribuzione del software perché permettono agli sviluppatori di ottimizzare le fasi di creazione del software per la
loro applicazione. Quindi per i fornitori, la creazione di una Virtual Appliance risulta essere più semplice ed economicamente più conveniente rispetto ad un Hardware
Appliance dato che l’applicazione è direttamente distribuita con il sistema operativo riducendo cosı̀ la necessità di effettuare certificazioni e i test di compatibilità
applicazione/OS. Per gli utenti finali, le Virtual Appliance offrono l’opportunità di
semplificare drasticamente la gestione del ciclo di vita del software attraverso l’utilizzo di un set di processi standard, automatizzati ed efficienti.
Una Virtual Appliance è descritta attraverso un formato run-time che illustra la con-
CAPITOLO 4. LA VIRTUALIZZAZIONE
53
figurazione delle immagini dei dischi adatti ad un particolare tipo di hypervisor. Tali
formati sono ottimizzati per l’esecuzione, mentre per un’efficiente distribuzioni sono
necessarie ulteriori caratteristiche che includono la portabilità, l’indipendenza dalla
piattaforma, la verifica ed i termini di licenza.
L’Open Virtual Machine Format (OVF) [7] è indipendente dall’hypervisor utilizzato, efficiente, facilmente estensibile e descrive Virtual Appliance composte da una o
più macchine virtuali. Esso mira a facilitare l’automazione, la gestione sicura non
solo delle singole macchine virtuali ma della Virtual Appliance vista come un’unita
funzionale.
4.5.1
Virtual Appliance
Una Virtual Appliance è un’applicazione preconfigurata che comprende una o più
macchine virtuali. Ciascuna VM è un’entità indipendente, installabile run-time, che
contiene un sistema operativo, informazioni riguardanti specifiche applicazioni e la
descrizione dell’hardware virtuale richiesto da ciascuna VM.
Il concetto di Virtual Appliance racchiude tutte quelle applicazioni per utenti finali
Figura 4.10: Virtual Appliance.
CAPITOLO 4. LA VIRTUALIZZAZIONE
54
accessibili dalla rete, come server DNS, database, o soluzioni CRM complete.
Di regola, un servizio software è implementato come un’applicazione multistrato composta da più macchine virtuali e comunicante attraverso la rete. I servizi spesso
comprendono altri servizi, i quali a loro volta possono essere applicazioni multistrato
oppure altri servizi. Questo modello è conosciuto come Service-Oriented-Architecture
(SOA). Il modello SOA si adatta chiaramente ad un’infrastruttura basata su Virtual
Appliance.
Ad esempio, consideriamo una tipica web application composta da 3 livelli, un livello
web che implementa una presentazione logica, uno strato in cui vi è un application
server che implementa una logica di business ed uno strato rappresentante un database di back-end. In primo luogo si potrebbe pensare di suddividere l’applicazione in
tre macchine virtuali, una per ogni livello. In questo modo, sarebbe possibile scalare
da uno a tre host fisici. Un altro approccio riguarda la possibilità di trattare ciascun
livello come un servizio in se stesso. Quindi ciascun livello potrebbe essere considerato
come un servizio multi-VM che fornisce una soluzione di tipo clusterizzata. Questo
approccio potrebbe fornire una grande scalabilità rispetto ai soli tre host fisici. Un
tipico scenario sarebbe quello di avere molti server web, un numero inferiore di application server ed uno o due database server. In questo modo, ciascun livello potrebbe
avere una scalabilità di poche o molte macchine fisiche, a seconda della richiesta, ed
inoltre ciascun livello potrebbe supportare più istanze di servizio di macchine virtuali.
CAPITOLO 4. LA VIRTUALIZZAZIONE
4.5.2
55
Obiettivi di progettazione
L’Open Virtual Machine Format (OVF) descrive un formato aperto, sicuro, portabile,
efficiente ed estensibile per la distribuzione ed il raggruppamento di collezioni di macchine virtuali. Diverse sono le proprietà principali del formato. È ottimizzato per la
distribuzione e supporta la verifica dei contenuti e il controllo di integrità secondo uno
standard, fornendo inoltre uno schema di base per la gestione delle licenze software.
Offre, poi, un approccio robusto e naturale per semplificare il processo d’installazione
della macchina virtuale nella piattaforma di virtualizzazione. I meta-dati nel file OVF
pilotano l’hypervisor nella creazione della macchina virtuale verificando la compatibilità con l’hardware virtuale locale. Il formato inoltre supporta l’aggregazione in un
singolo package con la descrizione di molteplici macchine virtuali ed è portabile in
quanto supporta una piattaforma di virtualizzazione neutrale. Esso, inoltre, è compatibile per l’intera gamma di formati di disco rigido virtuale utilizzati per le VMs di
oggi, ed è studiato per essere facilmente estensibile a formati che potrebbero sorgere
in futuro.
Bisogna anche aggiungere che il formato OVF non si basa sull’impiego di una piattaforma host specifica, e per questo è indipendente dalla piattaforma di virtualizzazione
e dal sistema operativo guest.
Da un punto di vista tecnico, OVF è un meccanismo di trasporto di macchine virtuali.
Come tale, esso si distingue dai vari formati di dischi virtuali: VMDK, VHD oppure
QCOW. Essi, infatti, non risolvono il problema della portabilità e non aiutano nella
personalizzazione della macchina virtuale al momento dell’installazione.
Nell’ambito di OVF è insito il concetto di certificazione ed integrità di una Virtual
CAPITOLO 4. LA VIRTUALIZZAZIONE
56
Appliance, permettendo cosı̀ alla piattaforma di virtualizzazione di determinare la
provenienza dell’applicazione, in maniera tale che l’utente sia in grado di fare le scelte appropriate.
OVF definisce sia un formato per la distribuzione di software da utilizzare attraverso
le macchine virtuali (OVF Package), che un ambiente nel quale esse verranno eseguite (OVF Environment). In particolare, OVF Package contiene un file xml che
descrive la Virtual Appliance ed un insieme di contenuti aggiuntivi, tipicamente dei
dischi virtuali. Nella versione 1.0, il file è suddiviso in sezioni, ognuna di esse definisce il funzionamento di una porzione dell’applicazione, ad esempio: virtual hardware,
dischi, la rete, le risorse richieste ed i parametri di personalizzazione. Tale file è estensibile, cosicché alcune risorse possono essere aggiunte in un secondo momento. Inoltre
sono supportati tutti i formati di dischi virtuali utilizzati dagli hypervisor moderni.
Di seguito è mostrato un esempio di file descrittore.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns1:Envelope xmlns:ns2="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/
CIM_VirtualSystemSettingData"xmlns:
ns1="http://schemas.dmtf.org/ovf/envelope/1"
xmlns:ns4="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/
CIM_ResourceAllocationSettingData"
xmlns:ns3="http://schemas.dmtf.org/wbem/wscim/1/common">
<ns1:References>
<ns1:File ns1:href="file:///srv/quickposta-0.1.qemu" ns1:id="master"/>
</ns1:References>
<ns1:DiskSection>
<ns1:Disk ns1:capacity="2048MB" ns1:diskId="master"/>
</ns1:DiskSection>
<ns1:NetworkSection>
<Info>Logical networks used in the package</Info>
<Network ns1:name="VM Network" custom:desiredCapacity="1 Gbit/s"/>
</ns1:NetworkSection>
<ns1:VirtualSystem ns1:id="Yavin-prova">
CAPITOLO 4. LA VIRTUALIZZAZIONE
57
<ns1:ProductSection ns1:class="net.emotivecloud.utils.ovf.OVFWrapper">
<ns1:Info>Some configuration information for the VM </ns1:Info>
<ns1:Property ns1:value="hda" ns1:type="string" ns1:key="master.target"/>
<ns1:Property ns1:value="ext3" ns1:type="string" ns1:key="master.format"/>
<ns1:Property ns1:value="hd" ns1:type="string" ns1:key="BOOT"/>
<ns1:Property ns1:value="kvm" ns1:type="string" ns1:key="HYPERVISOR"/>
</ns1:ProductSection>
<ns1:OperatingSystemSection ns1:id="76">
<ns1:Info>Specifies the operating system installed</ns1:Info>
<ns1:Description>Microsoft Windows Server 2008</ns1:Description>
</ns1:OperatingSystemSection>
<ns1:Info>VM description</ns1:Info>
<ns1:VirtualHardwareSection>
<ns1:Info>Virtual Hardware requirements</ns1:Info>
<ns1:Item>
<ns4:Description>Number of Virtual CPUs</ns4:Description>
<ns4:ElementName>1 virtual CPU</ns4:ElementName>
<ns4:InstanceID>0</ns4:InstanceID>
<ns4:ResourceType>3</ns4:ResourceType>
<ns4:VirtualQuantity>1</ns4:VirtualQuantity>
</ns1:Item>
<ns1:Item>
<ns4:AllocationUnits>MegaBytes</ns4:AllocationUnits>
<ns4:Description>Memory Size</ns4:Description>
<ns4:ElementName>500 MB of Memory</ns4:ElementName>
<ns4:InstanceID>1</ns4:InstanceID>
<ns4:ResourceType>4</ns4:ResourceType>
<ns4:VirtualQuantity>500</ns4:VirtualQuantity>
</ns1:Item>
<ns1:Item>
<ns4:AutomaticAllocation>true</ns4:AutomaticAllocation>
<ns4:Connection>VM Network</ns4:Connection>
<ns4:ElementName>Ethernet adapter on "VM Network "</ns4:ElementName>
<ns4:InstanceID>3</ns4:InstanceID>
<ns4:ResourceType>10</ns4:ResourceType>
<ns1:/Item>
<ns1:Item>
<ns4:AutomaticAllocation>true</ns4:AutomaticAllocation>
<ns4:ElementName>Hardisk 1</ns4:ElementName>
<ns4:HostResource>ovf://file/master</ns4:HostResource>
CAPITOLO 4. LA VIRTUALIZZAZIONE
58
<ns4:HostResource>ovf://disk/master</ns4:HostResource>
<ns4:InstanceID>6</ns4:InstanceID>
<ns4:ResourceType>17</ns4:ResourceType>
</ns1:Item>
</ns1:VirtualHardwareSection>
</ns1:VirtualSystem>
</ns1:Envelope>
I file descrittori presentano una serie di sezioni. Come sopra mostrato, le prime sezioni
definiscono i riferimenti ad un insieme di file esterni utilizzati dalla Virtual Appliance,
l’insieme dei dischi virtuali e le reti utilizzate dall’applicazione. A ciascun file, disco
o rete è dato un identificatore univoco. Il vero contenuto di un file OVF è elencato
all’interno del tag VirtualSystem. Nell’esempio esso contiene cinque sezioni:
• Product Section, che fornisce informazioni quali il nome del prodotto, il fornitore
ed ulteriori proprietà che possono essere utilizzate per la personalizzazione della
Virtual Appliance. Queste proprietà possono essere configurate al momento
dell’installazione, in genere chiedendo all’utente. Possono esserci più sezioni di
questo tipo.
• AnnotationSection, che è una libera forma di annotazione.
• EulaSection, che fornisce i termini di licenza della Virtual Appliance.
• HardwareSection, che descrive l’hardware virtuale. Questa è una sezione necessaria che descrive il tipo di hardware virtuale e l’insieme dei dispositivi che
la macchina virtuale necessita. Nel caso particolare è specificato: 500 MB di
memoria ram, una CPU, una rete virtuale ed un disco virtuale.
• OperatingSystemSection, che descrive il sistema operativo ospite.
CAPITOLO 4. LA VIRTUALIZZAZIONE
59
Creazione
È possibile creare un OVF semplicemente esportando da una piattaforma di virtualizzazione la macchina virtuale esistente in un OVF Package ed aggiungendo i dati
rilevanti necessari per la corretta installazione ed esecuzione, come ad esempio driver
o tools necessari per la gestione della memoria o dei dispositivi di I/O. Durante questo
processo, i dischi della macchina virtuale saranno compressi per rendere il package
più conveniente per la distribuzione.
Deployment
In questa fase, le macchine virtuali comprese nell’OVF Package vengono trasformate
in un formato run-time dipendente dalla piattaforma di virtualizzazione di destinazione, assegnando le risorse adeguate e l’hardware virtuale corretto. Durante questo
processo, la piattaforma verifica l’integrità dell’OVF, accertando che lOVF Package
non sia stato modificato in transito, e controllando che sia compatibile con l’hardware
virtuale locale. Inoltre, vengono configurate le reti, fisiche o virtuali, alle quali le macchine virtuali devono connettersi e vengono assegnate le risorse di storage, configurate
le CPU e personalizzate le proprietà livello di applicazione. La fase di deployment
istanzia una o più macchine virtuali con un profilo hardware che sia compatibile con
i requisiti posti nel descrittore OVF, e un insieme di dischi virtuali con il contenuto
specificato nel Package OVF.
CAPITOLO 4. LA VIRTUALIZZAZIONE
60
Portabilità
Il raggruppamento di macchine virtuali in OVF Package non garantisce una portabilità universale e non assicura una corretta installazione in tutte le piattaforme di
virtualizzazione gestite da diversi hypervisor. Di seguito vi sono alcuni fattori che
limitano la portabilità.
• Le macchine virtuali all’interno dei Package OVF possono contenere dischi in
formato non conosciuto dall’hypervisor che sta tentando l’installazione.
• Il software ospite installato può non supportare l’hardware virtuale gestito
dall’hypervisor.
• Il software ospite può non supportare l’architettura della CPU.
• La piattaforma di virtualizzazione potrebbe non capire una funzione richiesta
nel file OVF.
La portabilità di un OVF può essere suddivisa nei tre seguenti livelli:
• Funziona solo su un particolare prodotto di virtualizzazione e/o architettura di
CPU e/o hardware virtuale.
• Funziona solo per una specifica famiglia di hardware virtuale.
• Funziona su diverse famiglie di hardware virtuale.
Questa distinzione fa sı̀ che, per un uso all’interno di un’organizzazione, i primi due
livelli potrebbero bastare dato che il Package OVF è diffuso all’interno di un ambiente
CAPITOLO 4. LA VIRTUALIZZAZIONE
61
controllato. Mentre per le Virtual Appliance utilizzate a livello commerciale è necessario il terzo tipo di portabilita.
La descrizione dell’hardware virtuale all’interno del file OVF supporta tutti i tipi
di portabilità visti precedentemente, in quanto nella virtualhardwaresection è possibile introdurre qualunque descrizione hardware richiesta ed, addirittura, specificare
diverse alternative di configurazione.
Capitolo 5
Descrizione dell’implementazione
Passando adesso alla descrizione specifica dell’implementazione, bisogna dire che il
lavoro svolto nella presente tesi si è incentrato sul concetto di virtualizzazione in
CLEVER, un’architettura cloud open-source sviluppata all’interno dell’Università
di Messina e l’obiettivo è stato quello di estendere le funzionalità del cloud, al fine di
poter permettere a ciascun utente di utilizzare un ambiente virtuale secondo le sue
esigenze. In particolare, si è cercato di far sı̀ che qualsiasi fruitore dei servizi del cloud
sia in grado di creare un disco immagine con installato il sistema operativo desiderato,
a cui sarà possibile accedere solo tramite un account personale. A ciò si aggiunga che
esiste un elenco di applicazioni primarie installabili in maniera silenziosa, anche solo
eventualmente.
Nel capitolo che segue vengono descritte le soluzioni implementative adottate per
soddisfare le eventuali esigenze emergenti.
Il linguaggio di programmazione utilizzato per la parte implementativa è Java, per
62
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
63
restare in linea con l’intero processo di progettazione di CLEVER che si basa sul
modello della programmazione ad oggetti.
Avvalendosi del paradigma a plug-in di CLEVER, si è pensato di integrare all’interno
del Cluster Manager un agente in grado di occuparsi della creazione e gestione del
disco con il sistema operativo installato.
Una scelta implementativa riguarda poi l’utilizzo dell’hypervisor necessario per la
gestione delle istanze delle macchine virtuali. A tal fine sarà possibile scegliere senza
alcuna differenza particolare la soluzione open-source, VirtualBox, oppure utilizzare
gli strumenti per la gestione di piattaforme di virtualizzazione forniti dalle API di
Libvirt, che permettono di utilizzare le più importanti tecnologie di virtualizzazione,
come ad esempio Qemu e KVM.
Inoltre, si è introdotto in CLEVER lo standard OVF, versione 1.0, strumento che
descrive le caratteristiche delle macchine virtuali già adoperato in altre infrastrutture
cloud, come ad esempio OpenNebula. Per il parsing di questo tipo di file è stato
necessario l’utilizzo di specifiche librerie.
5.1
Agente CreateImage
Per l’implementazione del CreateImageAgent sono state seguite le linee guide fornite
nella documentazione di CLEVER. Si è utilizzato quindi un approccio a plug-in. Nel
dettaglio il CreateImageAgent estende la classe CmAgent, ed eredita da quest’ultima
il logger e la funzione main che gli permette di essere eseguito come un processo
separato.
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
64
Il costruttore di default di CreateImageAgent richiama il costruttore di default della
classe padre, e in questo modo viene correttamente configurato il ModuleCommunicator che permette la comunicazione intra-modulo in CLEVER attraverso il D-Bus
di sistema. Inoltre sempre nel costruttore di default viene settato il nome del logger
(ereditato dalla classe padre) attraverso il metodo getLogger implementato nella classe Logger.
Essendo la classe CmAgent una classe astratta, è stato necessario implementare nell’agente tutti i metodi astratti di tale classe ovvero initialization() e shutdown(). La
funzione initialization() provvede a creare un’istanza della classe CreateImagePlugin.
Nel plugin CreateImage è stato implementato un metodo (setOwner ) che permette
di passare l’handle del CreateImageAgent al plugin. Questa funzione viene richiamata nell’inizialization() del CreateImageAgent subito dopo la creazione del plugin. In
figura 5.1 è raffigurato il diagramma delle classi.
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
Figura 5.1: Diagramma delle classi CreateImage
65
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
5.1.1
66
CreateImage
La classe CreateImage implementa le funzionalità principali del progetto in modo da
raggiungere con successo l’obiettivo desiderato.
Possiamo descrivere il processo di creazione del disco in tre parti. La prima è relativa
alla creazione dell’immagine del sistema operativo da installare sul disco, mediante
un processo di installazione automatica. I file ISO dei sistemi operativi potranno
essere reperibili da una repository dalla quale si effettuerà il download. La seconda
parte descrive appunto l’installazione attraverso l’hypervisor di VirtualBox oppure
utilizzando gli strumenti per la gestione di piattaforme di virtualizzazione forniti
dall’open-source API Libvirt. Grazie ai quali è possibile utilizzare KVM e Qemu.
Una volta terminato il processo di installazione, in output vi sarà un file immagine
rappresentante il disco con il sistema operativo installato. Esso avrà un formato
dipendente dall’hypervisor utilizzato. La terza, ed ultima parte implementerà la
copia del file appena creato all’interno di un nodo del filesystem di CLEVER.
Si elencano di seguito i metodi della classe.
DownloadFromRepo
I file per la configurazione del sistema operativo da installare, se esplicitamente richiesto, saranno scaricati da una repository. Il metodo implementa questa funzionalità.
Ad esso è necessario passare come parametro il path logico del nodo del filesystem di
CLEVER che funge da repository.
Tale metodo, innanzitutto, interroga lo Storage Manager per sapere se effettivamente
il nodo esiste. Se sı̀, verrà effettuato il download dei file di configurazione relativi al
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
67
sistema operativo che si vuole installare. Inoltre, sarà scaricato il file contenente gli
eseguibili delle applicazioni da installare in modo silenzioso.
CreateAnswerFile
Il presente metodo si occupa della creazione dei file di risposta di Windows XP
(Winnt.sif ), di Windows Vista e Seven (AutoUnattend.xml ). A tal fine, sono necessari
i seguenti parametri di configurazione:
• Nome utente;
• Password;
• Organizzazione;
• Nome del computer;
• Sistema operativo da installare;
• Lista delle applicazioni da installare.
Naturalmente, potrebbero essere considerati anche dei parametri aggiuntivi per ottenere l’installazione desiderata, come ad esempio per la creazione di più partizioni del
disco, avere una risoluzione del display differente, etc...
Nel presente elaborato si è tenuta in considerazione un’installazione automatica del
sistema operativo, e per questo il file di risposta è creato in modo tale che non vi sia
interazione con l’utente durante il processo di installazione.
Sarà possibile, poi, personalizzare l’ambiente virtuale con applicazioni che saranno
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
68
installate al primo avvio del sistema in maniera silenziosa. Fra queste vi sono AVG
Antivirus, Scilab e LibreOffice.
CreateISO
La funzione non fa altro che copiare il file di risposta all’interno della directory
desiderata dell’immagine del sistema operativo da installare. In particolare:
• per Windows XP, nella cartella i386;
• per Windows Vista o Seven, nella root.
Successivamente, sarà necessario creare un nuovo CD avviabile. A tal fine, esistono
delle specifiche applicazioni (come nLite) che permettono di creare dei CD di installazione del sistema operativo personalizzati. In questo lavoro di tesi, è stato utilizzato
il comando mkisofs:
mkisofs -b boot.ima -c Catalog -o filename.iso pathname/
dove:
• -o filename.iso è il nome del file ISO che sarà creata;
• pathname/ è la directory entro la quale ci sono i file dai quali si creerà la ISO;
• -b boot.ima, è specificata l’immagine di boot da utilizzare per creare un CD
avviabile;
• -c Catalog, è specificato il file che rappresenta il catalogo da utilizzare.
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
5.1.2
69
Creazione del disco
Dopo aver creato l’immagine del sistema operativo, si potrà procedere nella creazione
del disco.
Sono stati cosı̀ valutati e studiati due hypervisor: VirtualBox e Qemu-KVM. A tal
proposito sono state create due classi, di seguito analizzate, per la creazione e la
gestione della macchina virtuale e, nello specifico, del disco associato, CallVbox e
CallLvirt.
CallVbox
Questa classe implementa le funzionalità principali di gestione dell’hypervisor di VirtualBox. A tal fine, sono state utilizzate delle librerie apposite, scritte in linguaggio
Java [18], che permettono l’interazione con VirtualBox.
Dopo aver creato un’istanza di VirtualBox attraverso il costruttore di classe, possono
essere richiamati i seguenti metodi.
Il metodo createvm riceve come parametri di ingresso:
• il sistema operativo da installare,
• il nome della macchina virtuale,
• la dimensione del disco desiderata,
• il path della directory locale dove salvare il disco.
L’obiettivo da raggiungere è creare una macchina virtuale e predisporla all’installazione del sistema operativo e delle applicazioni scelte. In particolare, verrà creato
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
70
il disco con la dimensione prescelta che sarà, quindi, montato in un IDE Controller
precedentemente progettato.
Successivamente, tramite il metodo mountISO verranno collegate, ai dispositivi di
lettura DVD creati, l’ immagine del sistema operativo ed il file immagine contenente
le applicazioni da installare. Una volta fatto ciò, è tutto pronto per avviare il processo
di installazione vero e proprio, mediante il metodo launchVM. Esso avrà il compito di
lanciare la virtual machine, all’interno della quale partirà l’installazione automatica
del sistema operativo.
CallLvirt
Anche questa classe ha come obiettivo la creazione del disco che si realizza tramite un
sistema operativo che però in questo caso viene installato utilizzando come hypervisor
Qemu oppure KVM. Sono state adoperate le librerie Libvirt Virtualization API [19].
Inizialmente, mediante il costruttore di classe, viene creata una connessione verso
l’hypervisor locale oppure remoto.
Successivamente, è necessario definire un dominio attraverso il metodo createvm che
prende come parametri in ingresso:
• il sistema operativo da installare,
• il nome della macchina virtuale,
• la dimensione del disco desiderata,
• il path della directory locale dove salvare il disco.
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
71
Tale metodo richiama ToXML che permette la creazione di un file XML, necessario
per la definizione dominio della macchina virtuale, grazie al quale verrà creato un
disco in formato raw.
Di seguito ‘e possibile vedere un esempio di dominio:
<domain type="kvm">
<name>WindowsXP</name>
<memory>512000</memory>
<os>
<type arch="i686">hvm</type>
<boot dev="cdrom" />
</os>
<features>
<acpi />
<apic />
</features>
<devices>
<interface type="network">
<source network="default" />
</interface>
<emulator>/usr/bin/kvm</emulator>
<disk type="file" device="cdrom">
<source file="/home/peppecal/Scrivania/Vmachine/WindowsVista.iso" />
<target dev="hdb" />
</disk>
<disk type="file" device="disk">
<source file="/home/peppecal/Scrivania/Vmachine/peppeXP13.img" />
<target dev="hda" />
</disk>
<disk type="file" device="cdrom">
<source file="/home/peppecal/Scrivania/Vmachine/file.iso" />
<target dev="hdc" />
</disk>
<graphics type="vnc" port="5904" />
</devices>
</domain>
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
72
Si può notare come sia necessario definire il nome della macchina virtuale, la memoria RAM, il tipo di sistema operativo che in questo caso è hvm (hardware virtual
machine), attraverso cui si abilita una full virtualization. All’interno del tag features
si indicano dei parametri che devono essere abilitati oppure no, in questo caso acpi
e apic sono inerenti alla configurazione e gestione energetica controllata dal sistema
operativo. All’interno del tag devices viene definita l’interfaccia di rete, l’emulatore
(in questo caso kvm) ed i dischi immagine utilizzati. Infine nel tag graphics viene
inserito il tipo di server da lanciare per visualizzare, ad esempio, una macchina virtuale in stato di running nel desktop remoto.
Una volta definito il dominio è possibile andarlo a creare, mediante il metodo startVM, che in definitiva permetterà la creazione del disco, lanciando la macchina virtuale
e quindi il programma di installazione del sistema operativo.
Copia del disco
Una volta creato il disco, l’agente CreateImage prevede di effettuare la copia all’interno del path logico di CLEVER. Questo è implementato dal metodo storedisk, che
riceve come parametro in ingresso il path di un nodo del filesystem di CLEVER all’interno del quale memorizzare il disco creato. Di seguito è mostrato il codice.
public void storedisk(String path) throws CleverException, FileSystemException{
ArrayList params = new ArrayList();
params.add(path);
params.add("");
MethodInvoker mi=new MethodInvoker("StorageManagerAgent","discoveryNode", true, params);
VFSDescription res=(VFSDescription)this.mc.invoke(mi);
VirtualFileSystem dest = new VirtualFileSystem();
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
73
dest.setURI(res);
FileObject file_d=dest.resolver(res, dest.getURI(),res.getPath1());
FileSystemManager mgr = VFS.getManager();
FileObject file_s = mgr.resolveFile(this.temp_path+this.machine+".img");
dest.cp(file_s, file_d);
}
Rimozione della VM
Dopo aver copiato il disco all’interno di uno specifico nodo del filesystem di CLEVER,
il passo successivo consiste nella rimozione completa della virtual machine creata nel
Cluster Manager. Tale operazione è svolta dal metodo destroyVm() implementato
nelle classi CallVbox e CallLvirt.
5.2
Shell di amministrazione
CLEVER è dotato di una shell di amministrazione, che permette di eseguire le principali operazioni per la gestione e l’utilizzo del middleware. Si tratta di una shell
testuale, grazie alla quale vengono invocate le funzioni fornite dagli agenti di CLEVER, passando gli eventuali parametri. La shell di CLEVER, per lo scambio di
messaggi con il middleware CLEVER, utilizza lo stesso server XMPP che permette
la comunicazione inter-nodo in CLEVER. Il ClusterCoordinator è infatti in ascolto
su una stanza del server XMPP riservata alla shell ed è quindi in grado di ricevere le
richieste provenienti dalla shell e smistarle verso l’agente di destinazione.
Con l’introduzione in CLEVER del CreateImageAgent è stata necessaria la creazione
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
74
di un nuovo comando per la shell, in modo da permettere di creare e gestire il disco
col sistema operativo installato.
createimage -f /path/local/file -p /path/logic [-r /path/logic/repo]
Tale comando prende in ingresso 3 parametri:
• (-f /path/local/file), il percorso locale del file XML che contiene le informazioni
necessarie per la creazione del disco;
• (-p /path/logic), il percorso logico del nodo del filesystem di CLEVER, all’interno del quale verrà memorizzato il disco.
• -r /path/logic/repo, è parametro opzionale. Se è indicato, fa in modo che il
Cluster Manager effettui il download da una repository della ISO del sistema
operativo da installare. Se, invece, si omette implica la ricerca dei file all’interno
di un path locale.
• (-xml ), opzione che permette di mostrare a video le richieste e risposte in
formato XML.
5.3
OVF Descriptor
Il comando della shell di amministrazione di CLEVER riceve come primo parametro
il path del file contenente tutte le informazioni necessarie alla creazione dell’immagine
del disco. A tal fine si è scelto l’utilizzo di un file OVF. Di seguito ne è presente un
esempio.
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
75
<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/
cim-schema/2/CIM_VirtualSystemSettingData"
xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/
cim-schema/2/CIM_ResourceAllocationSettingData"
xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1"
xmlns="http://schemas.dmtf.org/ovf/envelope/1"
xsi:schemaLocation="http://schemas.dmtf.org/ovf/envelope/1 ../dsp8023.xsd">
<References>
<File ovf:id="file1" ovf:href="/home/peppecal/Scrivania/Vmachine/WindowsXP.iso"/>
<File ovf:id="file2" ovf:href="/home/peppecal/Scrivania/Vmachine/file.iso"/>
</References>
<VirtualSystem ovf:id="peppeXP">
<ProductSection ovf:class="net.emotivecloud.utils.ovf">
<Property ovf:value="virtualbox" ovf:type="string" ovf:key="HYPERVISOR"/>
</ProductSection>
<ProductSection ovf:class="com.install.account">
<Property ovf:value="peppecal" ovf:type="string" ovf:key="USERNAME"/>
<Property ovf:value="image" ovf:type="string" ovf:key="PASSWORD"/>
<Property ovf:value="casa" ovf:type="string" ovf:key="ORG"/>
<Property ovf:value="pc_virt" ovf:type="string" ovf:key="PCNAME"/>
<Property ovf:value="10000000000" ovf:type="long" ovf:key="DISKSIZE"/>
<Property ovf:value="GuestAdditions" ovf:type="string" ovf:key="app0"/>
<Property ovf:value="avg" ovf:type="string" ovf:key="app1"/>
<Property ovf:value="scilab" ovf:type="string" ovf:key="app2"/>
<Property ovf:value="LibreOffice" ovf:type="string" ovf:key="app3"/>
</ProductSection>
<OperatingSystemSection ovf:id="67">
<Info>Guest Operating System</Info>
<Description>WindowsXP</Description>
</OperatingSystemSection>
<VirtualHardwareSection>
<Info>Virtual hardware requirements for a virtual machine</Info>
<Item>
<rasd:Caption>1 virtual CPU</rasd:Caption>
<rasd:Description>Number of virtual CPUs</rasd:Description>
<rasd:InstanceId>1</rasd:InstanceId>
<rasd:ResourceType>3</rasd:ResourceType>
<rasd:VirtualQuantity>1</rasd:VirtualQuantity>
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
</Item>
<Item>
<rasd:AllocationUnits>MegaBytes</rasd:AllocationUnits>
<rasd:Caption>512 MB of memory</rasd:Caption>
<rasd:Description>Memory Size</rasd:Description>
<rasd:InstanceId>2</rasd:InstanceId>
<rasd:ResourceType>4</rasd:ResourceType>
<rasd:VirtualQuantity>512</rasd:VirtualQuantity>
</Item>
<Item>
<rasd:Address>1</rasd:Address>
<rasd:BusNumber>1</rasd:BusNumber>
<rasd:Caption>ideController0</rasd:Caption>
<rasd:Description>IDE Controller</rasd:Description>
<rasd:InstanceId>4</rasd:InstanceId>
<rasd:ResourceSubType>PIIX4</rasd:ResourceSubType>
<rasd:ResourceType>5</rasd:ResourceType>
</Item>
<Item>
<rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
<rasd:Caption>Ethernet adapter on ’NAT’</rasd:Caption>
<rasd:Connection>NAT</rasd:Connection>
<rasd:InstanceId>5</rasd:InstanceId>
<rasd:ResourceSubType>PCNet32</rasd:ResourceSubType>
<rasd:ResourceType>10</rasd:ResourceType>
</Item>
<Item>
<rasd:AddressOnParent>0</rasd:AddressOnParent>
<rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
<rasd:Caption>cdrom1</rasd:Caption>
<rasd:Description>CD-ROM Drive</rasd:Description>
<rasd:HostResource>ovf://file/file1</rasd:HostResource>
<rasd:InstanceId>9</rasd:InstanceId>
<rasd:Parent>4</rasd:Parent>
<rasd:ResourceType>15</rasd:ResourceType>
</Item>
<Item>
<rasd:AddressOnParent>1</rasd:AddressOnParent>
<rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
<rasd:Caption>cdrom2</rasd:Caption>
76
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
77
<rasd:Description>CD-ROM Drive</rasd:Description>
<rasd:HostResource>ovf://file/file2</rasd:HostResource>
<rasd:InstanceId>10</rasd:InstanceId>
<rasd:Parent>4</rasd:Parent>
<rasd:ResourceType>15</rasd:ResourceType>
</Item>
</VirtualHardwareSection>
</VirtualSystem>
</Envelope>
Come è possibile notare, si tratta di un file descrittore XML adattato alle esigenze dell’Agente CreateImage. In particolare, dopo un’intestazione conforme allo
standard, sono presenti diverse sezioni.
Nella sezione References sono presenti le caratteristiche dei file esterni utilizzati e, nel
caso particolare, sono presenti i due file immagine ISO necessari per l’installazione
del sistema operativo con le applicazioni desiderate.
VirtualSystem è la sezione principale. Essa ha id come attributo, contenente come
valore il nome della macchina virtuale che si vuole creare. È risultata di grande aiuto
la possibilità di poter inserire all’interno di questa sezione più istanze di ProductSection, cosicché si potessero descrivere differenti gruppi di informazioni. Nell’esempio
sono presenti due classi:
• net.emotivecloud.utils.ovf, che contiene informazioni riguardanti il formato
dei file utilizzati ed il tipo di hypervisor (kvm o virtualbox) adoperato per la
creazione della macchina virtuale e quindi del disco;
• com.install.account, contenente tutte le altre informazioni aggiuntive riguardanti l’account, come:
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
78
– username;
– password;
– organizzazione;
– nome del pc;
– dimensione del disco;
– lista delle applicazioni.
Successivamente, vi è la OperatingSystemSection, che riguarda il sistema operativo
da installare, annotato all’interno del tag descripion.
Infine vi è la VirtualHardwareSection nella quale sono presenti tutte le caratteristiche
dell’hardware virtuale da utilizzare. La distinzione fra i vari componenti è effettuata
attraverso gli item. In questo caso, sussistono informazioni riguardanti il numero di
CPU virtuali da utilizzare, la dimensione della memoria RAM, nonché altre informazioni relative ai dischi, alla scheda di rete utilizzata, all controller USB, alla scheda
audio ed infine ai lettori CD-ROM utilizzati. Si evidenzia in particolare il riferimento
ai file immagine ISO da montare.
5.3.1
OVF Wrapper
Una volta passato come parametro il file OVF, è necessario effettuare un parsing
al fine di estrapolare le informazioni in esso contenute. A tal fine, si è utilizzato
un parser, le cui librerie sono presenti nel progetto OVF4ONE [20]. Si tratta di
un’implementazione Java di OCCI (Open Cloud Computing Interface) che utilizza
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
79
messaggi OVF ed il toolkit di cloud computing open-source, OpenNebula, come backend. Questa implementazione si basa sulle caratteristiche specifiche di OpenNebula,
ma non le impone. In pratica, OVF4ONE è un bridge fra OCCI ed OpenNebula
Cloud API (OCA), che traduce le chiamate ai metodi RestFul OCCI in chiamate
RestFul OCA, in maniera tale da tradurre i messaggi OVF in template di macchine
virtuali di OpenNebula.
Nella figura 5.2 di seguito riportata è mostrato il diagramma delle classi utilizzate
che permettono di effettuare il parsing del file OVF.
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
80
Figura 5.2: Diagramma delle classi OVF
La classe principale è OVFWrapperFactory. Essa viene richiamata per creare
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
81
un oggetto OVFWrapper contenente tutte le informazioni del file OVF. I metodi
implementati sono:
• parse(xml : String). Esso prende come parametro la stringa rappresentante
il file OVF e ne effettua l’unmarshalling, che permette la conversione del file
(rappresentato sotto forma di serie byte) in una struttura dati, che nel caso
particolare è un oggetto della classe EnvelopeType rappresentante l’intero
documento xml (compreso all’interno del tag Envelope). Tale oggetto viene
passato al metodo create.
• create(envelope : EnvelopeType). Esso estrapola tutte le informazioni contenute nell’oggetto envelope che a sua volta sarà composto da oggetti sempre più
specifici rappresentanti le sezioni interne del file OVF. Ad esempio, si potranno
avere oggetti di VirtualSystemType, ProductSectionType, DiscSectionType, VirtualHardwareSectionType e cosı̀ via. Di volta in volta saranno
prelevate le informazioni contenute in queste sezioni per formare un oggetto
OVFWrapper, che sarà il parametro di ritorno del metodo in considerazione.
• create(...). Tale metodo prende come parametri d’ingresso tutti i vari dati
già estratti necessari per la composizione di un oggetto OVFWrapper, quindi
segue una via alternativa rispetto al precedente metodo per la creazione di tale
oggetto.
• createDisk(...), createImage(...), createNetwork(...). Tali metodi vengono richiamati al momento della scansione della VirtualHardwareSection,
cioè della sezione contenente tutti i vari tipi di hardware virtuali contenuti nel
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
82
file OVF. Non appena si è in presenza di dischi, immagini ISO oppure reti si
richiamano i metodi in considerazione che creano oggetti contenenti le informazioni necessarie per configurare i vari tipi di hardware virtuale. Ad esempio, per
quanto riguarda i dischi, sono utili le informazioni sul path locale nel quale sono
memorizzati oppure la capacità in MegaByte. Per le reti è possibile andare a
prendere le informazioni riguardanti il nome, l’indirizzo IP o Mac.
La classe OVFAux è di ausilio alla classe OVFWrapperFactory. Essa implementa
infatti i metodi utili alla ricerca delle sotto-sezioni contenute nell’oggetto envelope.
La classe OVFWrapper, invece, contiene tutte le informazioni ottenute dal file OVF.
Ad esempio:
• memoryMB, la memoria ram;
• architecture, architettura;
• productProperties, tutte le varie informazioni contenute nelle sezioni ProductSection, memorizzate attraverso un’ HashMap, in cui ciascuna riga presenta
una chiave nota ed il valore;
• disks, i dischi;
• images, le immagini ISO;
• networks, le reti virtuali e fisiche;
• osProperties, il sistema operativo;
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
83
• accountProperties, tutte le informazioni riguardanti l’account del sistema
operativo da installare.
Infine le classi OVFDisk, OVFImage, OVFNetwork, come già enunciato in precedenza, rappresentano i vari dischi, le immagini e le reti della macchina virtuale che
si vuole istanziare attraverso il file OVF.
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
5.3.2
84
Agente OVFCompute
L’agente in esame, anch’esso facente parte del ClusterManager, è stato creato al fine
di effettuare il parsing del file OVF, creando cosı̀ un oggetto OVFWrapper nel quale
saranno memorizzate le informazioni contenute nel file.
Figura 5.3: Diagramma delle classi OVFComputeAgent
CAPITOLO 5. DESCRIZIONE DELL’IMPLEMENTAZIONE
85
Il file OVF, appunto, sarà passato attraverso il comando createimage, all’agente CreateImage, il quale invocherà il metodo getAccountSettings di OVFComputeAgent per
ottenere le informazioni desiderate.
La classe OVFCompute implementa le funzionalità principali per giungere all’obiettivo desiderato. Essa implementa i seguenti metodi:
• vmDescription(ovf : OVFWrapper). Esso prende come parametro un’oggetto OVFWrapper, precedentemente allocato e riempito delle informazioni necessarie presenti all’interno del file OVF, e ritorna un oggetto AccountSettings
avente tutti i dati riguardanti l’account e le proprietà del disco da creare.
• parse(path ovfXml : String). Questo metodo invece richiama l’omonimo
metodo della classe OVFWrapperFactory, descritto in precedenza, passandogli
il path del file OVF.
• getAccountSettings(path ovfXml : String). Esso riceve il percorso locale
del file OVF ed invoca prima il metodo parse, dal quale riceve un oggetto
OVFWrapper e successivamente il metodo vmDescription dal quale riceve un
oggetto di tipo AccountSettings che, a sua volta, sarà il suo parametro di
ritorno.
Capitolo 6
Test sperimentali
In questo capitolo verrà mostrato un tipico scenario di funzionamento dell’agente
CreateImage.
6.1
Configurazione delle macchine
Per il testbed sono state adoperate 3 macchine AMD64 facenti parte di un BladeCenter dell’IBM.
La prima fase ha richiesto la configurazione di queste tre lame, a tal fine si è scelto
di installare come sistema operativo la distro Scientific Linux 6.3 Basic Server [24].
È necessario installare la versione DVD per la presenza di bug nelle altre ISO di installazione.
Dopo aver configurato la rete si è passati all’installazione dei pacchetti necessari
all’avvio di Clever. In particolare su ciascuna lama è stato installato:
86
CAPITOLO 6. TEST SPERIMENTALI
87
• il demone dbus-launch che è necessario lanciare per la corretta comunicazione
dei moduli di Clever;
• VirtualBox-4.1-4.1.16 x86 64 che è la versione di VirtualBox utilizzata (potrebbe non funzionare con altre versioni);
• qemu-kvm, libvirt, python-virtinst, per la configurazione di libvirt.
Inoltre, su alcune lame sono stati montati dei server FTP ed SFTP per la verifica della
corretta memorizzazione dell’immagine del disco creata all’interno del path logico di
Clever. A tal fine si sono dovuti installare i demoni Proftpd e Vsftpd.
6.2
Scenario
In figura 6.1 viene presentato lo scenario per la realizzazione degli esperimenti. Come
detto precedentemente, sono state utilizzate tre macchine con indirizzi appartenenti
alla rete interna dell’Università di Messina ed un host che funge da repository:
• ing-clever-03 con IP: 212.189.207.106, nella quale è lanciata un’istanza di
CLEVER che, essendo l’unica, ha il Cluster Manager attivo;
• ing-clever-02 con IP: 212.189.207.105, utilizzata per la shell di amministrazione di CLEVER;
• ing-clever-01 con IP: 212.189.207.104, sulla quale è montato un server FTP,
come destinazione delle immagini dei dischi.
CAPITOLO 6. TEST SPERIMENTALI
88
• Minotauro con IP: 172.17.122.77, sulla quale è montato un server FTP, dal
quale viene effettuato il download della ISO del sistema operativo.
Figura 6.1: Scenario
Il test prevede che, una volta avviata l’istanza di CLEVER nella lama 03, venga
lanciato dalla shell di amministrazione posta nella lama 02 il comando:
createimage -f /root/Clever/configuration image.ovf -r peppecal/repository -p
peppecal/remoteftp1
passando tre parametri: il file OVF, il path logico del nodo del filesystem di CLEVER
utilizzato come repository ed il path logico del nodo sul quale memorizzare il disco
creato.
Ipotizzando di aver assegnato come nome della macchina virtuale CleverXP e di
CAPITOLO 6. TEST SPERIMENTALI
89
utilizzare come hypervisor VirtualBox, l’agente provvederà a creare il disco CleverXP.vmdk e memorizzarlo nella lama ing-clever-01.
Per verificare la corretta installazione del sistema operativo nel disco si adoperano le
funzioni già implementate in CLEVER che prevedono inizialmente la configurazione
del file VEDescription.xml, di seguito riportato:
<?xml version="1.0" encoding="UTF-8"?>
<org.clever.Common.VEInfo.VEDescription>
<os_guest_id>ubuntuGuest</os_guest_id>
<name>CleverVM</name>
<storage>
<org.clever.Common.VEInfo.StorageSettings>
<diskPath>peppecal/remoteftp1/CleverXP.vmdk</diskPath>
</org.clever.Common.VEInfo.StorageSettings>
</storage>
<cpu>
<numCpu>1</numCpu>
<coresXCpu>1</coresXCpu>
<frequency>0.0</frequency>
<architecture>X86</architecture>
</cpu>
<mem>
<size>512000</size>
</mem>
<network>
<org.clever.Common.VEInfo.NetworkSettings></org.clever.Common.VEInfo.NetworkSettings>
</network>
<desktop>
<username></username>
<password_user></password_user>
<password_vnc_vm></password_vnc_vm>
<ip_vnc></ip_vnc>
</desktop>
</org.clever.Common.VEInfo.VEDescription>
Dopodiché è necessario lanciare dalla shell di amministrazione di CLEVER il comando
registervm, che registrerà l’ambiente virtuale all’interno del database. Successivamen-
CAPITOLO 6. TEST SPERIMENTALI
90
te, tramite il comando createvm, al quale si passerà il nome dell’Host Manager per
il mapping VM/HM ed il nome della macchina virtuale registrato nel file sopra riportato (CleverVM ), verrà creata una copia del disco all’interno della repository di
CLEVER e predisposta la VM relativa. Infine, per l’avvio si adopererà il comando
startvm che prende come parametro solo il nome della VM.
Per visualizzare l’andamento dell’installazione del sistema operativo e per la gestione
della macchina virtuale con il sistema già installato è stato adoperato il tool rdesktop,
tool che permette la connessione verso desktop remoti utilizzando il protocollo RDP.
Lanciando il comando:
rdesktop -a 16 -N 212.189.207.106:3390
sarà possibile collegarsi attraverso la porta 3390 alla macchina virtuale avviata nella
lama ing-clever-03. Naturalmente, affinché ciò avvenga è stato necessario modifica le
impostazioni della macchina virtuale mettendo in ascolto un server RDP sulla porta
3390.
Capitolo 7
Conclusioni e sviluppi futuri
L’obiettivo preso di mira con la presente tesi è stato la progettazione e l’integrazione all’interno del middleware per il cloud computing, CLEVER, della funzionalità
di creazione di un disco immagine avente i requisiti richiesti da un qualsiasi utente
fruitore dei servizi del cloud. Ogni utente sarà cosı̀ capace di avviare il proprio ambiente virtuale indipendentemente sia dalla macchina che utilizza che dalla posizione
geografica nella quale si trova.
Inoltre, mediante l’introduzione dello standard OVF è stato rafforzato in CLEVER
il concetto di contestualizzazione, in modo tale da renderlo più simile alle altre infrastrutture cloud.
I risvolti del lavoro della presente tesi potrebbero essere molteplici, sia nell’ambito
delle installazioni automatiche che in relazione allo standard OVF.
Si potrebbero, infatti, approfondire tecniche di installazione automatica modificando
i file di risposta dei sistemi operativi secondo le più specifiche esigenze dell’utente.
91
CAPITOLO 7. CONCLUSIONI E SVILUPPI FUTURI
92
Ad esempio, creando più partizione del disco, o introducendo ulteriori applicazioni da
poter installare in maniera silenziosa. Inoltre, si potrebbero estendere le installazioni
su altri sistemi operativi. In tal senso, si è già proceduto in fase di sviluppo per i
sistemi LINUX [23].
In CLEVER, i possibili sviluppi futuri si incentrano sullo standard OVF. Infatti, l’utilizzo dei file OVF è limitato alla creazione del disco. Sono già stati implementati
dei metodi che gestiscono l’import e l’export di file OVF di macchine virtuali create
mediante hypervisor come VirtualBox, qemu-KVM o VMWare. Uno sviluppo futuro potrebbe far sı̀ che da un file si potrebbe direttamente istanziare una macchina
virtuale presupponendo che già il disco con il sistema operativo installato sia stato
creato.
Bibliografia
[1] T. Lindholm and F. Yellin. Java virtual machine specification. Addison-Wesley,
Longman Publishing Co., Inc., 1999. 38
[2] F. Bellard. Qemu, a fast and portable dynamic translator. Proceedings of the annual conference on USENIX Annual Technical Conference, (Berkeley, CA, USA),
2005. 38
[3] Bochs. Bochs. http://bochs.sourceforge.net/, 38
[4] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori. Kvm: the linux virtual
machine monitor. Proceedings of the Linux Symposium, vol. 1, 2007. 39
[5] R. P. Goldberg. Architectural Principles for Virtual Computer Systems. Harvard
University, 1973. 40
[6] VMWare. Understanding Full Virtualization, Paravirtualization and Hardware.
http://www.vmware.com/files/pdf/VMware paravirtualization.pdf 42
[7] DMTF Standard. Open Virtualization Format Specification. 2010 53
93
BIBLIOGRAFIA
94
[8] National Institute of Standards and Technology (NIST). http://www.nist.gov/
18
[9] 7th
FLOOR.
Cloud
Computing:
l’ultimo
trend
di
Internet.
http://www.7thfloor.it/2007/10/04/cloud-computing-lultimo-trend-di-internet,
18
[10] Filippo Dalla Gassa.
Virtualizzazione e Cloud Computing Analisi del tool
OpenNebula per la gestione di cloud privati. 2011. 19
[11] I. Foster, C. Kesselman, S. Tuecke. The anatomy of the Grid:Enabling scalable
virtual organization. The Intl. Jrnl. of High Performance Computing Applications,
2001. 20
[12] I. Foster. Globus Toolkit Version 4: Software for Service-Oriented Systems. IFIP
Int. Conf. on Network and Parallel Computing, Springer-Verlag LNCS 3779, 2006.
20
[13] I. Foster. What is the Grid? A Three Point Checklist. 2002. 21
[14]
What is Cloud Computing?.
Whatis.com.http://searchsoa.techtarget.com
/sDefinition/0,,sid26 gci1287881,00.html, 2008. 22
[15] A. Chervenak, I. Foster, C. Kesselman, C. Salisbury, S. Tuecke. The Data Grid:
Towards an Architecture for the Distributed Management and Analysis of Large
Scientific Datasets. Jrnl. of Network and Computer Applications, 2001.
[16] I. Foster, J. Vöckler, M. Wilde, Y. Zhao. Chimera: A Virtual Data System for
Representing, Querying, and Automating Data Derivation. SSDBM, 2002.
BIBLIOGRAFIA
95
[17] Filippo Bua. CLEVER: Progettazione di un middleware distribuito per il cloud
computing. 2010. 6, 25
[18] Version 4.1.16 2004-2012 Oracle Corporation Programming Guide and Reference.
69
[19] http://libvirt.org/formatdomain.html Libvirt Virtualization API. 70
[20] Gian Uberto Lauri. http://cloud.eng.it/ovf4one/index.html. 2011. 7, 78
[21] Giovanni Valenti. Integrazione di VMware e Virtual Desktop Web-Based in
Clever Cloud. 2012. 29
[22] Giancarlo Alteri. Gestione avanzata di risorse di storage in ambito Cloud. 2012.
27
[23] Andrea Cannistrà.
Installazione automatica di sistemi linux virtualizzati in
ambiente cloud. 2012. 92
[24] https://www.scientificlinux.org/download. 86