Gestione di Macchine Virtuali in Ambiente Cloud - MEDAlics · Molti sono i sistemi operativi che...

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

2.3 Installazione silenziosa di applicazioni . . . . . . . . . . . . . . . . . . 15

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 . . . . . . . . . . . . . . . . . . . . . . . . 29

4 La Virtualizzazione 32

4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Modalita 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

4.5 Lo standard OVF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.5.1 Virtual Appliance . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.5.2 Obiettivi di progettazione . . . . . . . . . . . . . . . . . . . . 55

5 Descrizione dell’implementazione 62

5.1 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 5

4.9 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 e destinata a crescere in futuro. Per

questo si e determinata una rapida evoluzione ed un notevole incremento dei servizi

offerti disponibili su richiesta al singolo utente, il quale potra gestirli come preferisce

indipendentemente dalla macchina che si trova ad utilizzare ed in qualunque parte

del mondo si trovi.

In tal senso l’Universita degli Studi di Messina, in particolare la Facolta 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, modu-

lare e fault-tolerance, nonche di utilizzare un approccio a plugin rendendo semplice

la modifica della struttura, l’integrazione di nuove tecnologie e l’aggiunta di nuove

funzionalita.

Il lavoro svolto nella presente tesi si e incentrato sul concetto di virtualizzazione in

6

CAPITOLO 1. INTRODUZIONE 7

CLEVER. Tale tecnologia, che fonda le sue radici nel passato, ormai gode di notevo-

le diffusione grazie al fatto che garantisce numerosi benefici in termini di flessibilita,

scalabilita della struttura e notevole riduzione dei costi.

L’obiettivo considerato ha portato ad estendere le funzionalita del cloud, al fine di

poter permettere a ciascun utente di disporre di un proprio ambiente virtuale, rea-

lizzato secondo le sue esigenze. In questo modo, il generico fruitore dei servizi del

cloud potra creare un disco immagine con il sistema operativo desiderato, al quale

sara possibile accedere solo con un proprio account personale. Una volta creato il

disco, l’utente potra creare ed avviare la macchina virtuale associata tramite delle

operazioni gia 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 e indipendente dall’hypervi-

sor utilizzato, non si basa sull’impiego di una piattaforma host specifica e per questo

e indipendente dalla piattaforma di virtualizzazione e dal sistema operativo guest.

Tali file OVF sono stati adattati secondo i requisiti richiesti ed e stato, quindi, im-

plementato 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 e una tecnologia utilizzata per l’installazione o l’aggiorna-

mento di un sistema operativo con un intervento minimo o nullo da parte dell’utente,

ecco perche essa spesso viene definita unattended (non presidiata).

L’installazione automatica e 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 piu file di rispo-

sta (answer file).

Un file di risposta e 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 piu siti, risulterebbe molto utile avvalersi di un’installazione

di tipo unattended.

L’installazione automatica arreca dunque numerosi vantaggi agli utenti, nonche agli

assemblatori, agli amministratori di sistema e, in generale, a chi debba configurare

un elevato numero di macchine in modo standardizzato.


Alcuni vantaggi sono i seguenti.

• si realizzano meno errori durante l’installazione. Mediante un’installazione au-

tomatica non vi e 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. Utilizzan-

do lo stesso file di risposte per installare e configurare il sistema operativo, e

possibile garantire che tutti i computer di un’organizzazione siano impostati

esattamente nello stesso modo.

• si riducono i tempi di installazione. L’installazione automatica e piu veloce ri-

spetto a quella interattiva perche non e necessario attendere che gli amministra-

tori o i tecnici inseriscano le informazioni di configurazione richieste; al program-

ma di installazione, infatti, bastera leggere il file delle risposte precedentemente

settato.

• si determinano minori costi di supporto. Riducendo al minimo gli errori du-

rante il processo di installazione, aumentando la coerenza dei computer di una

struttura, e riducendo il tempo necessario al setup, e possibile ridurre i costi

globali di sostegno all’interno di un’organizzazione aziendale.

Molti sono i sistemi operativi che permettono di eseguire delle installazioni auto-

matiche, tra cui anche i sistemi Linux e Microsoft Windows, ed il principio di

funzionamento e piuttosto simile nei vari casi.

Di seguito si esaminera l’installazione unattended di Windows Seven.


2.2 Windows Seven

A partire dal sistema operativo Windows Vista, il programma di installazione ha

subito notevoli cambiamenti che hanno reso le installazioni piu veloci e piu consistenti

rispetto a quelle di Windows XP. Si utilizza, infatti, l’Image Based Setup(IBS), una

nuova tecnologia basata sull’utilizzo di piu file immagine in formato WIM (Windows

Imaging) con le seguenti proprieta:

• Memorizzazione di piu 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 piu semplice e veloce.

Per questo, l’immagine del sistema operativo e memorizzata in un unico file, in-

stall.wim, memorizzato all’interno della cartella sources. Vi e 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, di-

verse versioni del sistema operativo, come: Windows Seven Home premium,

Professional, Ultimate.

L’installazione di Windows Seven puo essere divisa nelle seguenti fasi.


Preinstallation Phase

In questa fase viene configurata l’installazione del sistema operativo. Le attivita

eseguite possono essere cosı suddivise:

• Configurazione di Windows Setup: l’installazione viene configurata utiliz-

zando 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: e possibile configurare sia

singolo che multi-boot.

• Configurazione dei servizi offline: vengono applicati gli aggiornamenti nel-

l’immagine di Windows 7, tra cui correzioni software, language pack ed altri

aggiornamenti di sicurezza.

Online Configuration Phase

Durante questa fase, Windows 7 esegue attivita di personalizzazione relative all’iden-

tita del computer, che rendono questa nuova installazione di Windows unica.


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 e presente la sezione

oobeSystem nel file di risposta quest’ultima viene elaborata. Infine vi e l’esecuzione

della sezione Windows Welcome, che e conosciuta anche come Machine Out-Of-Box-

Experience (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 e un file XML (AutoUnattend.xml), grazie al

quale e possibile automatizzare tutto o parte del processo di installazione. Esso puo

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 e possibile inserire, ad esempio, eventuali driver

aggiuntivi da installare.

• Windows Image. In questo riquadro viene visualizzata l’immagine di Windo-

ws attualmente aperta (e necessario aprire un file .wim per creare un file di

risposta).


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, e 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.


• Offline servicing. Passo di configurazione utilizzabile per aggiungere dei driver

all’immagine di Windows.

• Specialize. Passaggio utilizzato dal sistema per configurare impostazioni speci-

fiche di rete.

• AuditSystem. Si realizza il passaggio solo quando l’installazione avviene in mo-

dalita di controllo. Questa modalita e utilizzata per l’aggiunta di varie persona-

lizzazioni 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’installa-

zione.

2.3 Installazione silenziosa di applicazioni

L’installazione silenziosa e una modalita di installazione dei programmi in cui non c’e

interazione con l’utente, quindi non si realizza una visualizzazione di un’interfaccia

oppure di finestre di dialogo.

In questo modo, il programma si installera con le impostazioni di default, cioe:

• accettazione automatica della licenza;


• creazione di scorciatoie;

• installazione dei tool aggiunti.

Per eseguire un’installazione silenziosa, basta eseguire il file di installazione con de-

terminati parametri.

Il metodo classico per ricavare i parametri di installazione e quello di utilizzare il

comando “/?”.

La procedura pero, non e delle piu veloci e non sempre questo comando funziona.

Possiamo pero utilizzare un comodo strumento (che si integra nel menu 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 menu con-

testuale “More Options” ⇒ “Installer Tools” ⇒ “Identify Installer”.

Tali parametri variano in base al “package installer”, dipendono cioe dal sistema

d’installazione utilizzato per la specifica applicazione. I parametri piu comuni di in-

stallazione 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 piu comuni package installer sono:

• Inno Setup;

• Install Shield Installer;

• Nullsoft Scriptable Install System (NSIS);


• Windows Installer Service (MSI packages);

• Wise Installer.

Capitolo 3

Cloud Computing

Il Cloud Computing, secondo il National Institute of Standards and Technology

(NIST): e 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 rila-

sciate con costi di gestione o interazioni con il fornitore minimali [8].

L’ambito e quello di calcolo distribuito e lo scenario e quindi quello di un utente che

con un qualsiasi device (PC, tablet, smartphone) ed una connessione ad Internet puo

accedere al cloud che gli fornisce tutti i servizi e i dati richiesti [9]. E evidente cosı

come il Cloud Computing faccia in campo IT cio che quotidianamente viene fatto

mediante la fornitura di elettricita, 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 quantita 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 verifichera. 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 puo essere comparata alle tecnologie esistenti,

come Grid Computing, Utility Computing, Service Computing, e calcolo distribuito

in generale.

In particolare, il Cloud Computing puo essere considerato l’evoluzione del Grid Com-

puting, da cui prende le mosse. L’evoluzione e la conseguenza di un cambiamento

di scenario che si e realizzato col passaggio da una tecnologia che fornisce storage e

grandi risorse di elaborazione (nel caso del Grid), ad una la cui economia e fondata

sull’erogazione di servizi e risorse piu astratte.

Per quanto riguarda, invece, l’Utility Computing, esso non consiste in un nuovo pa-

radigma 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’elettricita

ed alla rete telefonica.

L’Utility Computing e, tipicamente, implementato utilizzando altre infrastrutture di

calcolo, come le griglie, e aggiungendo dei servizi aggiuntivi di monitoraggio.

Un’infrastruttura cloud puo essere invece utilizzata all’interno di una societa oppure

esposta pubblicamente come Utility Computing.

La figura 3.1 ci mostra una panoramica del rapporto fra il Cloud Computing e gli


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 no-

services. Il Grid Computing si sovrappone a tutti questi domini, pero presenta una

minore scalabilita rispetto ai supercomputer ed ai clouds.

Il Grid Computing si propone di consentire la condivisione delle risorse e di problem-

solving in organizzazioni virtuali dinamiche e multi-istituzionali [11]. Caratteristica

chiave di questo modello e rappresentata dal fatto che le griglie provvedono a fornire

un paradigma di calcolo distribuito che si estende su piu organizzazioni virtuali (VO),

in cui ognuna di essa puo essere costituita da istituzioni fisicamente distribuite o

progetti correlati logicamente. L’obiettivo di tale paradigma e quello di consentire

la condivisione delle risorse associate ad ambienti distribuiti dinamici. L’approccio

adottato come standard de facto [12], e quello di costruire un ambiente uniforme di

calcolo mediante la definizione di protocolli di rete standard, fornendo dei middleware


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 general-

purpose e offrire qualita 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 comunita 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 e 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


• 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 piu alto di servizi forniti. Attraverso

questa tecnologia e 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. E l’acronimo di Platform as a Service, cioe la virtualizzazione di una

piattaforma. L’utente che utilizza tale servizio non deve occuparsi di gestire

l’infrastruttura sottostante, in quando questa operazione e stata gia effettuata

dal fornitore del servizio. Cio rappresenta anche una limitazione in quanto


l’utente per realizzare la propria applicazione dovra necessariamente utilizzare

un’infrastruttura predefinita senza poterla adattare alle proprie esigenze.

• IaaS. E l’acronimo di Infrastructure as a Service ed e il servizio piu vicino a cio

che forma il cloud. Al cliente viene fornito un “computer virtuale” caratterizzato

da una certa quantita di ram, un certo numero di cpu, un’interfaccia di rete

e una certa quantita di storage. L’utente ha la possibilita di installare un

qualsiasi sistema operativo e di installare i programmi che preferisce. Inoltre,

ha a disposizione un “computer virtuale”, quindi non dovra preoccuparsi di

eventuali guasti al sistema, in quanto vengono gestiti dal fornitore del servizio.

Generalmente tale servizio e tariffato ad ore di utilizzo, anche se esistono delle

soluzioni flat con fatturazione periodica. Un esempio e il servizio EC2/S3 fornito

da amazon.

3.3 Virtualizzazione

La virtualizzazione e la caratteristica che differenzia maggiormente il Cloud Compu-

ting 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 piu attivita, e ciascuna di esse

utilizzasse tutte le risorse disponibili, all’interno di un cloud e 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


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 perche viene garantito il consolidamento dei server e delle applica-

zioni: piu applicazioni possono essere eseguite sullo stesso server, piu 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, e necessaria la virtualizzazione, perche non e

realizzabile altrimenti a livello hardware.

• La virtualizzazione consente comunque una maggiore affidabilita, perche per-

mette 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 reattivita, in quanto possono

essere automatizzati sia provisioning delle risorse che monitoraggio e manuten-

zione, e le risorse comuni possono essere memorizzate all’interno della cache e

riutilizzate successivamente.


3.4 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 compu-

ting e, allo stesso tempo, per consentire l’interconnessione con altri cloud al fine di

formare un cloud federato.

CLEVER e interamente sviluppato in linguaggio Java ed offre un’architettura alta-

mente scalabile, modulare, tollerante ai guasti e flessibile; quest’ultimo requisito e

stato raggiunto integrando nella struttura di CLEVER il paradigma a plug-in, grazie

al quale e possibile modificare alcune parti del middleware o aggiungerne di nuove

senza mettere mani nel codice, bensı modificando degli opportuni file di configurazio-

ne [17].

CLEVER e 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 e 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, e pero

necessaria la presenza di un server XMPP, che rappresenta il cuore delle comunica-

zioni inter-modulo e di un database distribuito, su cui verranno salvati tutti i dati

necessari al corretto funzionamento e ripristino del middleware.

CLEVER e 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’ho-

st sottostante per monitorarne le risorse fisiche. Sopra gli Host Manager troviamo


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 ri-

cevendo 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, cia-

scuno dei quali e 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 e necessario che su ogni host sia presente


un modulo Host Manager, e almeno un Cluster Manager per tutto il cluster. Tutta-

via per aumentare la fault tollerance dell’architettura, saranno contemporaneamente

presenti, su host differenti, piu Cluster Manager. Solo uno di questi svolgera 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 e un processo a se stante, ed e quindi

possibile la comunicazione fra i vari agenti sfruttando il bus di sistema.

La comunicazione esterna e necessaria per lo scambio di messaggi fra il Cluster Ma-

nager e gli Host Manager; i moduli girano infatti su nodi differenti e non e quindi

possibile utilizzare il bus di sistema per la comunicazione. Per permettere la comuni-

cazione inter-nodo si e 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-


terno del cluster. In tal senso, l’utente puo decidere di caricare immediatamente un

dato all’interno del cluster, oppure in alternativa ha la facolta di specificare un’ubi-

cazione esterna, che puo essere un server FTP o HTTP di sua proprieta. 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 puo creare in qual-

siasi momento e che al suo interno puo 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 puo fare un link anche ad uno specifico path fisico all’interno del

file system (mount node) in maniera del tutto trasparente. E un nodo foglia, il

che significa che non puo avere nodi figli.

• Mount node che e un particolare nodo del file system nel quale sono effettiva-

mente contenuti dei dati che e possibile esplorare. Anch’esso e un nodo foglia,

pertanto non e 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 piu ad alto livello, mentre i nodi mount sono quelli che hanno


un significato fisico piu a basso livello. L’utente, specificando un determinato path,

e in grado di eseguire l’attraversamento dell’albero in modo del tutto trasparente.

Tale path e costituito da due parti, il path logico che e il percorso dalla root ad un

qualsiasi nodo clever (clever node,link node, mount node ) e il path fisico che e 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 e affidata al componente Vir-

tualization Manager presente nel modulo Cluster Manager.

Mediante la classe VirtualizationManagerClever vengono offerte molte funziona-

lita 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 col-

legate. Per una maggiore trattazione sull’implementazione delle suddette classi si

rimanda il lettore al seguente lavoro di tesi [21]. In dettaglio, i parametri dell’am-

biente 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>


<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 dovra

specificare il percorso virtuale dell’immagine.

La creazione di una macchina virtuale consiste nel provvedere al recupero dell’imma-

gine del disco, rendendola disponibile all’hypervisor. Si recupera l’oggetto VEDe-

scription, lo si de-serializza e si estrae il diskPath relativo all’ubicazione dell’imma-

gine della VM. Se le informazioni relative al nuovo ambiente virtuale sono corrette,

nel senso che non esiste gia una VM con lo stesso nome oppure l’immagine del disco

e realmente presente nel path logico fornito, allora mediante il processo di creazione


viene copiato il disco all’interno del repository di Clever.

L’operazione di avvio provvedera al lancio della macchina virtuale appena registrata

e creata.

Capitolo 4

La Virtualizzazione

4.1 Introduzione

La virtualizzazione e espressione di un trend in evoluzione negli ultimi anni in ambito

informatico che comunque affonda le sue radici nel passato, come qualsiasi avveni-

mento legato alla tecnologia.

Si tratta di un sistema di tipo time-sharing che consente a piu 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 fisica-

mente, 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 piu 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., adotto 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 difficolta nel-

l’implementazione del sistema operativo perche doveva supportare un singolo utente.

Tecnicamente, con il termine virtualizzazione si intende la possibilita 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:

• Scalabilita dell’infrastruttura, sia per un’eventuale richiesta di maggio-

re potenza di calcolo, sia per una richiesta di disponibilita 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 e possibile migliorare il rap-

porto 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.


• Sicurezza: possibilita di controllare e interrompere eventuali attivita pericolose

in quanto tutte confinate nella virtual machine sotto il completo controllo del

sistema che ne governa l’esecuzione (hypervisor).

4.2 Modalita 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 e 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


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 piu applicazioni o server Web in modo centralizzato, come un’istanza

unica, offrendo una topologia piu sicura e resistente rispetto a un’architettura con

accesso diretto a ogni server Web. Si tratta di un modello di virtualizzazione uno-a-

molti applicabile a qualsiasi tipo di architettura e deployment di applicazioni, in cui

un unico server rappresenta piu server accessibili tramite un proxy inverso.

Virtualizzazione di rete

La virtualizzazione di rete consiste nella possibilita di riferirsi a risorse di rete senza

utilizzare la loro reale locazione fisica.

Un esempio puo 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 necessita 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 e dato dalla VPN (Virtual Area Network). Essa e 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


dagli altri computer presenti nella rete intermedia.

Virtualizzazione dei dispositivi di storage

La virtualizzazione del sistema di storage permette di rappresentare i dati indipen-

dentemente dalla posizione e dalle caratteristiche dello storage, rendendo possibile un

miglior utilizzo delle risorse, un ripristino delle risorse piu rapido e una semplificazio-

ne dei requisiti di spazio, energia e raffreddamento. Tuttavia, l’efficacia dei vantaggi

ottenibili con tale tecnologia dipende dalla completezza della soluzione di virtualiz-

zazione del sistema di storage e dalla qualita della sua integrazione con l’architettura

per la gestione dei dati critici.

Virtualizzazione del sistema operativo

Oltre a rappresentare il tipo di virtualizzazione piu diffuso, i sistemi operativi virtua-

lizzati, o macchine virtuali, sono un componente indispensabile dell’infrastruttura IT,

che permette di eseguire sulla stessa piattaforma hardware piu sistemi standard, for-

nendo 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 e altro che un insieme di componenti hardware e periferi-

che implementate via software, conosciuto con il nome di Virtual Machine (Macchina


Figura 4.1: Virtualizzazione del sistema operativo

Virtuale). La Virtual Machine permette l’esecuzione di un sistema operativo guest ed

una o piu applicazioni che eseguono sopra di esso. Ogni Virtual Machine a sua volta

esegue sopra ad uno strato di virtualizzazione chiamato tecnicamente Hypervisor (Su-

pervisore), il quale possiede un Virtual Machine Monitor (VMM). L’hypervisor e il

componente chiave che idealmente deve operare in maniera trasparente senza pesare

con la propria attivita sul funzionamento e sulle prestazioni dei sistemi operativi.

4.3 Virtual Machine e Hypervisor

In dipendenza delle specifiche applicazioni, e 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


di sicurezza per incapsulare programmi in esecuzione, fornendo un set di risorse

altamente controllato. Le macchine virtuali appartenenti a questa classe posso-

no 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 diretta-

mente dalla sandbox stessa, la quale cosı e 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 e 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’hard-

ware che utilizza, come le VT-X di Intel o le SVM di AMD, garantendo cosı

delle prestazioni migliori. Per esempio, considerando l’estensione di virtualizza-

zione di Intel VT-X 6, possono essere introdotte in particolare due transizioni:


VMentry e VMExit, e, semplificando il discorso, si puo 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 piu del tempo d’esecuzione dovuto all’ove-

rhead del VMM, alla ridotta disponibilita di risorse, che potrebbe fare andare in

swap il programma in esecuzione, ed ai dispositivi I/O agganciati, perche 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 esclu-

siva competenza del VMM, senza interferenze da parte delle VM.


L’hypervisor puo essere suddiviso in tre generici moduli: dispatcher, allocator ed

interpreter. Il compito del dispatcher e 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 e 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


• Il VMM di tipo 2 e un normale processo in esecuzione nell’ambito del sistema

operativo host. Gestisce direttamente le macchine virtuali, che sono suoi sotto-

processi, mentre la gestione hardware e demandata al sistema ospitante. In virtu

di quanto detto la sua implementazione dovrebbe essere piu 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 piu alti e, normalmente, in esso vi e il sistema opera-

tivo. Il codice eseguito in questo livello puo essere in esecuzione in modalita: system

space, kernel mode oppure supervisor mode. Qualsiasi altro tipo di codice, come


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 ope-

rativo 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 e 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 e realizzato da un apposito software che si occupa di

emulare l’hardware necessario traducendo le istruzioni eseguite dal sistema ospite in


qualcosa che il sistema operativo ospitante sia in grado di eseguire. Come e possibile

intuire, la traduzione di ogni singola istruzione e molto onerosa a livello di potenza

di calcolo, per ovviare a cio e 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 e 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 poiche 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),

e possibile velocizzare notevolmente l’esecuzione dei sistemi guest mappando diretta-

mente memoria e CPU (per quanto riguarda le istruzioni accessibili). Questo limite

rende pero impossibile virtualizzare sistemi x86 64 se il sistema operativo di base e

i386 (come nel caso di VMWare ESX). Questo succede perche l’architettura i386

prevede l’esecuzione di codice in due modalita:

• Real Mode: dove ogni processo ha completo accesso a tutto l’hardware (tale

modalita e 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 piu restrittivi man mano che

si procede verso l’esterno.


Figura 4.5: Virtualizzazione completa.

Hardware Assisted Virtualization

Conosciuta anche come Accelerated Virtualization oppure con nomi diversi a secon-

da del produttore, ad esempio Xen la chiama Hardware Virtual Machine (HVM),

Virtual Iron la chiama Native Virtualization. Questa tecnica si appoggia a specia-

li funzioni della CPU (Intel VT e AMD-V) e permette l’esecuzione direttamente in

hardware di alcune chiamate della macchina virtuale. La piu importante conseguenza

di questo supporto in hardware e il superamento del limite della Full Virtualization:

grazie a queste estensioni e infatti possibile avere come guest sistemi x86 64 nono-

stante il sistema ospitante sia i386. Occorre precisare che l’attuale virtualizzazione

assistita si occupa di aiutare solamente funzioni di CPU e memoria; tutte le funziona-

lita di I/O sono ancora emulate. Esistono gia delle specifiche per permettere a diverse

istanze virtuali di condividere schede PCI Express.

Vengono introdotte due nuove modalita operative, trasversali ai livelli di protezione

dell’architettura (ring level): la modalita Root e la modalita non Root. Sia i guest che


gli host potranno operare sempre al giusto ring-level (generalmente 0 in kernel-mode,

3 in user-mode), ma solo il VMM potra accedere alla modalita Root, che fornisce

l’accesso a tutte le funzionalita di gestione della virtualizzazione implementate dalle

estensioni.

Figura 4.6: Hardware assisted virtualization.


ParaVirtualization

Essa e una tecnica in cui il sistema operativo virtualizzato riesce a comunicare diret-

tamente con il Motore di Virtualizzazione (hypervisor). Questo comporta la necessita

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 mo-

dificato e driver personalizzati. Il vantaggio nell’usare la ParaVirtualization consiste

nella maggior velocita di esecuzione delle applicazioni utente. Xen e Microsoft

Virtual Server sono esempi di software che utilizzano ParaVirtualization.

Figura 4.7: Paravirtualization.


Containers

Questa tipologia di Virtualizzazione e ancora piu slegata dall’hardware fisico e piu

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 e 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.


Hosted

L’ultima tipologia di virtualizzazione forse e piu 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 virtua-

lizzazione 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.


4.4.1 Esempi di virtualizzatori

Di seguito vengono trattati alcuni tipi di virtualizzatori.

Qemu

Qemu, acronimo di Quick EMUlator, e un software che implementa un particolare

sistema di emulazione che permette di ottenere un’architettura nuova e disgiunta in

un’altra che si occupera 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. Puo essere utilizzato per lanciare differenti sistemi

operativi senza il riavvio del PC.

• User mode emulation (solo per Linux). Qemu puo essere lanciato come processo

Linux compilato per una CPU o per un’altra.

KVM

Kernel-based Virtual Machine e un sistema full-virtualization esclusivamente per

GNU Linux, su piattaforma x86, che puo essere facilmente installato su qualsiasi di-

stribuzione, l’unico prerequisito e possedere un processore con istruzioni Intel-VT o

AMD-V.

Esso consiste in un modulo kernel (kvm.ko) che fornisce la virtualizzazione dell’in-

frastruttura di base ed un modulo specifico per il processore in uso (kvm-intel.ko o


kvm-amd.ko) a seconda dei casi.

KVM presenta un approccio diverso rispetto ad altri sistemi di virtualizzazione pro-

fessionale. Esso non prevede infatti l’utilizzo di un hypervisor a se stante, ma utilizza

il kernel Linux a questo scopo, questa e una scelta strategica decisiva che porta nume-

rosi vantaggi. Uno tra tutti e il fatto che grazie a questo, il team di sviluppo di KVM,

non deve preoccuparsi di scrivere da se driver per le periferiche o tool di gestione,

tutto cio e offerto dal kernel Linux.

L’integrazione di KVM con il kernel e 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 facilita di gestione. Grazie a cio infatti la macchina che

ospita la VM, se dotata di hardware sufciente, risulta sempre uida e dimostra buona

velocita di risposta, anche quando il sistema ospitato e sotto sforzo.

VirtualBox

VirtualBox e 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,

e possibile creare una macchina virtuale tramite l’interfaccia grafica per poi control-


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 sara presentato al sistema guest come hard disk virtuale. Quando il si-

stema 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; e la CLI di Virtualbox e fornisce funzionalita avanzate non

accessibili tramite l’interfaccia grafica.

• VBoxSDL; e 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 e 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).


4.5 Lo standard OVF

La rapida adozione delle infrastrutture virtuali ha messo in luce la necessita 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 e

certificato che essa possa essere trasferita fra differenti ISV(Indipendent Software

Vendor) come un’unita pre-configurata, risulta essere molto vantaggioso ed allettan-

te. 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 e 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, nonche per la configura-

zione ed il lancio della Virtual Appliance in qualsiasi piattaforma di virtualizzazione.

Le Virtual Appliance hanno cambiato il paradigma di distribuzione del software per-

che 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 risul-

ta essere piu semplice ed economicamente piu conveniente rispetto ad un Hardware

Appliance dato che l’applicazione e direttamente distribuita con il sistema opera-

tivo riducendo cosı la necessita di effettuare certificazioni e i test di compatibilita

applicazione/OS. Per gli utenti finali, le Virtual Appliance offrono l’opportunita di

semplificare drasticamente la gestione del ciclo di vita del software attraverso l’utiliz-

zo di un set di processi standard, automatizzati ed efficienti.

Una Virtual Appliance e descritta attraverso un formato run-time che illustra la con-


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 portabilita, l’indipendenza dalla

piattaforma, la verifica ed i termini di licenza.

L’Open Virtual Machine Format (OVF) [7] e indipendente dall’hypervisor utilizza-

to, efficiente, facilmente estensibile e descrive Virtual Appliance composte da una o

piu 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 e un’applicazione preconfigurata che comprende una o piu

macchine virtuali. Ciascuna VM e un’entita 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.


accessibili dalla rete, come server DNS, database, o soluzioni CRM complete.

Di regola, un servizio software e implementato come un’applicazione multistrato com-

posta da piu 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 e 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 e un application

server che implementa una logica di business ed uno strato rappresentante un data-

base 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 possibilita 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 scalabilita rispetto ai soli tre host fisici. Un

tipico scenario sarebbe quello di avere molti server web, un numero inferiore di appli-

cation server ed uno o due database server. In questo modo, ciascun livello potrebbe

avere una scalabilita di poche o molte macchine fisiche, a seconda della richiesta, ed

inoltre ciascun livello potrebbe supportare piu istanze di servizio di macchine virtuali.


4.5.2 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 mac-

chine virtuali. Diverse sono le proprieta principali del formato. E ottimizzato per la

distribuzione e supporta la verifica dei contenuti e il controllo di integrita 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 compati-

bilita con l’hardware virtuale locale. Il formato inoltre supporta l’aggregazione in un

singolo package con la descrizione di molteplici macchine virtuali ed e portabile in

quanto supporta una piattaforma di virtualizzazione neutrale. Esso, inoltre, e com-

patibile per l’intera gamma di formati di disco rigido virtuale utilizzati per le VMs di

oggi, ed e 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 piatta-

forma host specifica, e per questo e indipendente dalla piattaforma di virtualizzazione

e dal sistema operativo guest.

Da un punto di vista tecnico, OVF e 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 portabilita e non aiutano nella

personalizzazione della macchina virtuale al momento dell’installazione.

Nell’ambito di OVF e insito il concetto di certificazione ed integrita di una Virtual


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 scel-

te 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 ese-

guite (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 e suddiviso in sezioni, ognuna di esse defini-

sce il funzionamento di una porzione dell’applicazione, ad esempio: virtual hardware,

dischi, la rete, le risorse richieste ed i parametri di personalizzazione. Tale file e esten-

sibile, cosicche alcune risorse possono essere aggiunte in un secondo momento. Inoltre

sono supportati tutti i formati di dischi virtuali utilizzati dagli hypervisor moderni.

Di seguito e 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">


<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: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>



<ns1:/Item>

<ns1:Item>

<ns4:AutomaticAllocation>true</ns4:AutomaticAllocation>

<ns4:ElementName>Hardisk 1</ns4:ElementName>

<ns4:HostResource>ovf://file/master</ns4:HostResource>


<ns4:HostResource>ovf://disk/master</ns4:HostResource>



</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 e dato un identificatore univoco. Il vero contenuto di un file OVF e 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 proprieta che possono essere utilizzate per la personalizzazione della

Virtual Appliance. Queste proprieta possono essere configurate al momento

dell’installazione, in genere chiedendo all’utente. Possono esserci piu sezioni di

questo tipo.

• AnnotationSection, che e una libera forma di annotazione.

• EulaSection, che fornisce i termini di licenza della Virtual Appliance.

• HardwareSection, che descrive l’hardware virtuale. Questa e una sezione ne-

cessaria che descrive il tipo di hardware virtuale e l’insieme dei dispositivi che

la macchina virtuale necessita. Nel caso particolare e specificato: 500 MB di

memoria ram, una CPU, una rete virtuale ed un disco virtuale.

• OperatingSystemSection, che descrive il sistema operativo ospite.


Creazione

E possibile creare un OVF semplicemente esportando da una piattaforma di virtua-

lizzazione 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

piu 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 destina-

zione, assegnando le risorse adeguate e l’hardware virtuale corretto. Durante questo

processo, la piattaforma verifica l’integrita 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 mac-

chine virtuali devono connettersi e vengono assegnate le risorse di storage, configurate

le CPU e personalizzate le proprieta livello di applicazione. La fase di deployment

istanzia una o piu 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.


Portabilita

Il raggruppamento di macchine virtuali in OVF Package non garantisce una porta-

bilita 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 portabilita.

• 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 puo non supportare l’hardware virtuale gestito

dall’hypervisor.

• Il software ospite puo non supportare l’architettura della CPU.

• La piattaforma di virtualizzazione potrebbe non capire una funzione richiesta

nel file OVF.

La portabilita di un OVF puo 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 e diffuso all’interno di un ambiente


controllato. Mentre per le Virtual Appliance utilizzate a livello commerciale e neces-

sario il terzo tipo di portabilita.

La descrizione dell’hardware virtuale all’interno del file OVF supporta tutti i tipi

di portabilita visti precedentemente, in quanto nella virtualhardwaresection e possi-

bile 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 e incentrato sul concetto di virtualizzazione in

CLEVER, un’architettura cloud open-source sviluppata all’interno dell’Universita

di Messina e l’obiettivo e stato quello di estendere le funzionalita del cloud, al fine di

poter permettere a ciascun utente di utilizzare un ambiente virtuale secondo le sue

esigenze. In particolare, si e 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 sara possibile accedere solo tramite un account personale. A cio 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 e 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 e 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 sara 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 piu importanti tecnologie di virtualizzazione,

come ad esempio Qemu e KVM.

Inoltre, si e introdotto in CLEVER lo standard OVF, versione 1.0, strumento che

descrive le caratteristiche delle macchine virtuali gia adoperato in altre infrastrutture

cloud, come ad esempio OpenNebula. Per il parsing di questo tipo di file e 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 e 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.


Il costruttore di default di CreateImageAgent richiama il costruttore di default della

classe padre, e in questo modo viene correttamente configurato il ModuleCommuni-

cator 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 clas-

se Logger.

Essendo la classe CmAgent una classe astratta, e stato necessario implementare nel-

l’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 e stato implementato un metodo (setOwner) che permette

di passare l’handle del CreateImageAgent al plugin. Questa funzione viene richiama-

ta nell’inizialization() del CreateImageAgent subito dopo la creazione del plugin. In

figura 5.1 e raffigurato il diagramma delle classi.


Figura 5.1: Diagramma delle classi CreateImage


5.1.1 CreateImage

La classe CreateImage implementa le funzionalita 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 e 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 effettuera 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 e possibile utilizzare KVM e Qemu.

Una volta terminato il processo di installazione, in output vi sara un file immagine

rappresentante il disco con il sistema operativo installato. Esso avra un formato

dipendente dall’hypervisor utilizzato. La terza, ed ultima parte implementera 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 richie-

sto, saranno scaricati da una repository. Il metodo implementa questa funzionalita.

Ad esso e 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ı, verra effettuato il download dei file di configurazione relativi al


sistema operativo che si vuole installare. Inoltre, sara 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 otte-

nere l’installazione desiderata, come ad esempio per la creazione di piu partizioni del

disco, avere una risoluzione del display differente, etc...

Nel presente elaborato si e tenuta in considerazione un’installazione automatica del

sistema operativo, e per questo il file di risposta e creato in modo tale che non vi sia

interazione con l’utente durante il processo di installazione.

Sara possibile, poi, personalizzare l’ambiente virtuale con applicazioni che saranno


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, sara necessario creare un nuovo CD avviabile. A tal fine, esistono

delle specifiche applicazioni (come nLite) che permettono di creare dei CD di installa-

zione del sistema operativo personalizzati. In questo lavoro di tesi, e stato utilizzato

il comando mkisofs :

mkisofs -b boot.ima -c Catalog -o filename.iso pathname/

dove:

• -o filename.iso e il nome del file ISO che sara creata;

• pathname/ e la directory entro la quale ci sono i file dai quali si creera la ISO;

• -b boot.ima, e specificata l’immagine di boot da utilizzare per creare un CD

avviabile;

• -c Catalog, e specificato il file che rappresenta il catalogo da utilizzare.


5.1.2 Creazione del disco

Dopo aver creato l’immagine del sistema operativo, si potra 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 funzionalita principali di gestione dell’hypervisor di Vir-

tualBox. 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 e creare una macchina virtuale e predisporla all’installa-

zione del sistema operativo e delle applicazioni scelte. In particolare, verra creato


il disco con la dimensione prescelta che sara, 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 cio, e tutto pronto per avviare il processo

di installazione vero e proprio, mediante il metodo launchVM. Esso avra il compito di

lanciare la virtual machine, all’interno della quale partira 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 pero 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, e 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.


Tale metodo richiama ToXML che permette la creazione di un file XML, necessario

per la definizione dominio della macchina virtuale, grazie al quale verra 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>


Si puo notare come sia necessario definire il nome della macchina virtuale, la memo-

ria RAM, il tipo di sistema operativo che in questo caso e 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 vir-

tuale in stato di running nel desktop remoto.

Una volta definito il dominio e possibile andarlo a creare, mediante il metodo start-

VM, che in definitiva permettera 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’in-

terno del path logico di CLEVER. Questo e implementato dal metodo storedisk, che

riceve come parametro in ingresso il path di un nodo del filesystem di CLEVER al-

l’interno del quale memorizzare il disco creato. Di seguito e 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();


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 e svolta dal metodo destroyVm() implementato

nelle classi CallVbox e CallLvirt.

5.2 Shell di amministrazione

CLEVER e dotato di una shell di amministrazione, che permette di eseguire le prin-

cipali 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 CLE-

VER, 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 e infatti in ascolto

su una stanza del server XMPP riservata alla shell ed e quindi in grado di ricevere le

richieste provenienti dalla shell e smistarle verso l’agente di destinazione.

Con l’introduzione in CLEVER del CreateImageAgent e stata necessaria la creazione


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’in-

terno del quale verra memorizzato il disco.

• -r /path/logic/repo, e parametro opzionale. Se e 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 e scelto l’utilizzo di un file OVF. Di seguito ne e presente un

esempio.



<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>


</Item>

<Item>

<rasd:AllocationUnits>MegaBytes</rasd:AllocationUnits>

<rasd:Caption>512 MB of memory</rasd:Caption>

<rasd:Description>Memory Size</rasd:Description>



<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:ResourceSubType>PIIX4</rasd:ResourceSubType>


</Item>

<Item>

<rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>

<rasd:Caption>Ethernet adapter on ’NAT’</rasd:Caption>

<rasd:Connection>NAT</rasd:Connection>


<rasd:ResourceSubType>PCNet32</rasd:ResourceSubType>


</Item>

<Item>

<rasd:AddressOnParent>0</rasd:AddressOnParent>


<rasd:Caption>cdrom1</rasd:Caption>

<rasd:Description>CD-ROM Drive</rasd:Description>

<rasd:HostResource>ovf://file/file1</rasd:HostResource>


<rasd:Parent>4</rasd:Parent>


</Item>

<Item>

<rasd:AddressOnParent>1</rasd:AddressOnParent>


<rasd:Caption>cdrom2</rasd:Caption>


<rasd:Description>CD-ROM Drive</rasd:Description>

<rasd:HostResource>ovf://file/file2</rasd:HostResource>


<rasd:Parent>4</rasd:Parent>


</Item>

</VirtualHardwareSection>

</VirtualSystem>

</Envelope>

Come e possibile notare, si tratta di un file descrittore XML adattato alle esi-

genze 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 e la sezione principale. Essa ha id come attributo, contenente come

valore il nome della macchina virtuale che si vuole creare. E risultata di grande aiuto

la possibilita di poter inserire all’interno di questa sezione piu istanze di ProductSec-

tion, cosicche 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 riguar-

danti l’account, come:


– username;

– password;

– organizzazione;

– nome del pc;

– dimensione del disco;

– lista delle applicazioni.

Successivamente, vi e la OperatingSystemSection, che riguarda il sistema operativo

da installare, annotato all’interno del tag descripion.

Infine vi e la VirtualHardwareSection nella quale sono presenti tutte le caratteristiche

dell’hardware virtuale da utilizzare. La distinzione fra i vari componenti e effettuata

attraverso gli item. In questo caso, sussistono informazioni riguardanti il numero di

CPU virtuali da utilizzare, la dimensione della memoria RAM, nonche altre informa-

zioni 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, e necessario effettuare un parsing

al fine di estrapolare le informazioni in esso contenute. A tal fine, si e 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


messaggi OVF ed il toolkit di cloud computing open-source, OpenNebula, come back-

end. Questa implementazione si basa sulle caratteristiche specifiche di OpenNebula,

ma non le impone. In pratica, OVF4ONE e 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 e mostrato il diagramma delle classi utilizzate

che permettono di effettuare il parsing del file OVF.


Figura 5.2: Diagramma delle classi OVF

La classe principale e OVFWrapperFactory. Essa viene richiamata per creare


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 e 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 con-

tenute nell’oggetto envelope che a sua volta sara composto da oggetti sempre piu

specifici rappresentanti le sezioni interne del file OVF. Ad esempio, si potranno

avere oggetti di VirtualSystemType, ProductSectionType, DiscSection-

Type, VirtualHardwareSectionType e cosı via. Di volta in volta saranno

prelevate le informazioni contenute in queste sezioni per formare un oggetto

OVFWrapper, che sara il parametro di ritorno del metodo in considerazione.

• create(...). Tale metodo prende come parametri d’ingresso tutti i vari dati

gia 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 ven-

gono richiamati al momento della scansione della VirtualHardwareSection,

cioe della sezione contenente tutti i vari tipi di hardware virtuali contenuti nel


file OVF. Non appena si e in presenza di dischi, immagini ISO oppure reti si

richiamano i metodi in considerazione che creano oggetti contenenti le informa-

zioni 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 capacita in MegaByte. Per le reti e possibile andare a

prendere le informazioni riguardanti il nome, l’indirizzo IP o Mac.

La classe OVFAux e 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 Produc-

tSection, 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;


• accountProperties, tutte le informazioni riguardanti l’account del sistema

operativo da installare.

Infine le classi OVFDisk, OVFImage, OVFNetwork, come gia enunciato in pre-

cedenza, rappresentano i vari dischi, le immagini e le reti della macchina virtuale che

si vuole istanziare attraverso il file OVF.


5.3.2 Agente OVFCompute

L’agente in esame, anch’esso facente parte del ClusterManager, e 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


Il file OVF, appunto, sara passato attraverso il comando createimage, all’agente Crea-

teImage, il quale invochera il metodo getAccountSettings di OVFComputeAgent per

ottenere le informazioni desiderate.

La classe OVFCompute implementa le funzionalita principali per giungere all’obiet-

tivo desiderato. Essa implementa i seguenti metodi:

• vmDescription(ovf : OVFWrapper). Esso prende come parametro un’og-

getto OVFWrapper, precedentemente allocato e riempito delle informazioni ne-

cessarie presenti all’interno del file OVF, e ritorna un oggetto AccountSettings

avente tutti i dati riguardanti l’account e le proprieta 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, sara il suo parametro di

ritorno.

Capitolo 6

Test sperimentali

In questo capitolo verra 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 BladeCen-

ter dell’IBM.

La prima fase ha richiesto la configurazione di queste tre lame, a tal fine si e scelto

di installare come sistema operativo la distro Scientific Linux 6.3 Basic Server [24].

E necessario installare la versione DVD per la presenza di bug nelle altre ISO di in-

stallazione.

Dopo aver configurato la rete si e passati all’installazione dei pacchetti necessari

all’avvio di Clever. In particolare su ciascuna lama e stato installato:

86

CAPITOLO 6. TEST SPERIMENTALI 87

• il demone dbus-launch che e necessario lanciare per la corretta comunicazione

dei moduli di Clever;

• VirtualBox-4.1-4.1.16 x86 64 che e la versione di VirtualBox utilizzata (po-

trebbe 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’Universita di Messina ed un host che funge da repository:

• ing-clever-03 con IP: 212.189.207.106, nella quale e 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 amministrazio-

ne di CLEVER;

• ing-clever-01 con IP: 212.189.207.104, sulla quale e montato un server FTP,

come destinazione delle immagini dei dischi.


• Minotauro con IP: 172.17.122.77, sulla quale e 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


utilizzare come hypervisor VirtualBox, l’agente provvedera a creare il disco Cle-

verXP.vmdk e memorizzarlo nella lama ing-clever-01.

Per verificare la corretta installazione del sistema operativo nel disco si adoperano le

funzioni gia implementate in CLEVER che prevedono inizialmente la configurazione

del file VEDescription.xml, di seguito riportato:


<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>

Dopodiche e necessario lanciare dalla shell di amministrazione di CLEVER il comando

registervm, che registrera l’ambiente virtuale all’interno del database. Successivamen-


te, tramite il comando createvm, al quale si passera il nome dell’Host Manager per

il mapping VM/HM ed il nome della macchina virtuale registrato nel file sopra ri-

portato (CleverVM ), verra creata una copia del disco all’interno della repository di

CLEVER e predisposta la VM relativa. Infine, per l’avvio si adoperera 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 gia installato e 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

sara possibile collegarsi attraverso la porta 3390 alla macchina virtuale avviata nella

lama ing-clever-03. Naturalmente, affinche cio avvenga e 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 e stato la progettazione e l’integrazio-

ne all’interno del middleware per il cloud computing, CLEVER, della funzionalita

di creazione di un disco immagine avente i requisiti richiesti da un qualsiasi utente

fruitore dei servizi del cloud. Ogni utente sara cosı capace di avviare il proprio am-

biente virtuale indipendentemente sia dalla macchina che utilizza che dalla posizione

geografica nella quale si trova.

Inoltre, mediante l’introduzione dello standard OVF e stato rafforzato in CLEVER

il concetto di contestualizzazione, in modo tale da renderlo piu simile alle altre infra-

strutture 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 piu specifiche esigenze dell’utente.

91

CAPITOLO 7. CONCLUSIONI E SVILUPPI FUTURI 92

Ad esempio, creando piu 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 e gia proceduto in fase di sviluppo per i

sistemi LINUX [23].

In CLEVER, i possibili sviluppi futuri si incentrano sullo standard OVF. Infatti, l’u-

tilizzo dei file OVF e limitato alla creazione del disco. Sono gia 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 futu-

ro potrebbe far sı che da un file si potrebbe direttamente istanziare una macchina

virtuale presupponendo che gia 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 an-

nual 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. Vockler, 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 Cannistra. Installazione automatica di sistemi linux virtualizzati in

ambiente cloud. 2012. 92

[24] https://www.scientificlinux.org/download. 86

Gestione di Macchine Virtuali in Ambiente Cloud - MEDAlics · Molti sono i sistemi operativi che...

Documents

Transcript of Gestione di Macchine Virtuali in Ambiente Cloud - MEDAlics · Molti sono i sistemi operativi che...