2.
VIRTUALIZZAZIONE MEDIANTE PARTIZIONAMENTO
In questo capitolo verranno prese in considerazione le soluzioni tecnologiche e gli approcci implementativi della virtualizzazione basata su partizionamento (Figura 5).
In particolare, nel primo paragrafo si descriveranno le soluzioni tecnologiche più utilizzate, mentre
nel secondo verranno discussi i due approcci implementativi più diffusi, ovvero quello della virtualizzazione completa e quello della paravirtualizzazione. Si tenga presente che la classificazione adottata ha lo scopo di mettere in evidenza i diversi approcci implementativi che stanno alla
base dei progetti e dei prodotti descritti, ma che non è perfettamente applicabile nel caso di soluzioni ibride.
Per concludere (paragrafo 2.3), questo capitolo affronterà la discussione dei supporti hardware per
la virtualizzazione delle due maggiori case costruttrici di processori (Intel e AMD).
2.1
SOLUZIONI TECNOLOGICHE
2.1.1 HARDWARE PARTITIONING
Questi sistemi permettono la suddivisione di un sistema di elaborazione in diverse macchine tramite una definizione delle risorse a livello hardware; si associano quindi ad ogni macchina una o più
board del sistema ognuna con i propri processori e la propria memoria. Questa tecnica si utilizza
per superare il limite dei processori (socket) presenti su una singola board.
Queste tecniche non permettono la condivisione delle risorse e la riallocazione ottimale; d’altra
parte hanno il vantaggio di non avere overhead per la gestione della virtualizzazione in quanto i
confini di ogni macchina sono definiti a livello hardware.
Alcuni esempi di prodotti sono nPartition8 della HP e Dynamic System Domains9 della SUN.
2.1.2 HYPERVISOR
Col termine hypervisor si intende quello strato di software che permette solamente l’astrazione
dell’hardware fisico. Generalmente viene caricato all’avvio del sistema di elaborazione e non integra nessuna funzionalità di gestione di macchine virtuali.
8
http://h20341.www2.hp.com/hpux11i/cache/323751-0-0-0-121.html
9
http://www.sun.com/servers/highend/dr_sunfire/
- 14 -
App
App
App
App
App
Guest OS
Guest OS
Guest OS
(Linux)
(NetBSD)
(Windows)
VM
VM
VM
Hypervisor
Hardware
Figura 6: Sistema virtualizzato tramite hypervisor
La
Figura 6 mostra come l’hypervisor permetta la condivisione dell’hardware fisico tra diverse macchine virtuali10. Ovviamente, l’hardware rilevato da ogni macchina virtuale differisce sia dal punto
di vista qualitativo che da quello quantitativo rispetto a quello fisico: ad esempio, se il server fisico
possiede una scheda video ATI, l’hypervisor potrebbe presentarla come una VGA standard.
Come descritto meglio nel prossimo paragrafo, per avere una gestione completa delle macchine
virtuali (gestione del ciclo di vita, gestione delle priorità, …) è necessario disporre di una componente aggiuntiva che a seconda delle architetture può essere o non essere incorporata all’interno
dell’hypervisor.
2.1.3 VIRTUAL MACHINE MONITOR
Il VMM è il software vero e proprio che gestisce la condivisone delle risorse hardware e il ciclo di
vita di ogni macchina virtuale; in particolare i compiti di un moderno VMM sono:
10
•
esporre alle macchine virtuali le opportune interfacce hardware;
•
gestire l’interazione tra le diverse macchine virtuali;
•
garantire l’isolamento tra le macchine virtuali;
•
garantire la stabilità del sistema, impedendo alle macchine virtuali di poter eseguire istruzioni privilegiate in modo non controllato.
Queste macchine vengono chiamate anche macchine guest o VM (Virtual Machine)
- 15 -
A seconda che sia ospitato da un sistema operativo nativo o da un hypervisor, il VMM viene chiamato OS-hosted VMM oppure Hypervisor-Hosted VMM.
Alcuni esempi della prima tipologia sono: Microsoft Virtual Server11, Microsoft Hyper-V12 (stand
alone edition), VMware server13, Virtual Box14, Parallels Server15.
Alcuni esempi della seconda tipologia sono: Microsoft Hyper-V, Xen16 e relativi prodotti derivati
da esso (OracleVM17, VirtualIron18, SUN xVM19), VMware ESX server20, Parallels Server Bare
Metal21, Linux KVM22.
Come si può notare, alcune aziende sviluppatrici di prodotti per la virtualizzazione (per esempio
VMware e Microsoft), rilasciano sia la versione Hypervisor-Hosted sia la versione OS-hosted.
I sistemi VMM Hypervisor-Hosted solitamente sono più complessi in quanto devono essere dotati
di tutti i driver necessari a supportare l’hardware virtualizzato. Per tale ragione solitamente essi
sono certificati solo per determinati sistemi di elaborazione.
I VMM OS-hosted invece sono più semplici (in quanto sono a tutti gli effetti delle applicazioni) a
scapito però di una minore efficienza rispetto ai VMM Hypervisor-Hosted.
11
http://www.microsoft.com/italy/server/virtualserver/Default.mspx
12
http://www.microsoft.com/windowsserver2008/en/us/hyperv-main.aspx
13
http://www.vmware.com/products/server/
14
http://www.virtualbox.org/
15
http://www.parallels.com/it/virtualization/server/
16
http://www.xen.org
17
http://www.oracle.com/lang/it/technologies/virtualization/index.html
18
http://www.virtualiron.com/
19
http://www.sun.com/software/products/xvmserver/index.xml
20
http://www.vmware.com/products/vi/esx/
21
http://www.parallels.com/it/virtualization/server/
22
http://www.linux-kvm.org/page/Main_Page
- 16 -
UnHosted VMM
Hosted VMM
Figura 7: Differenza fra Hosted VMM e UnHosted VMM
2.1.4 OS VIRTUALIZATION
Questa tecnica, a differenza delle altre, inserisce lo strato di virtualizzazione fra sistema operativo e
applicazioni, come schematizzato nella figura seguente:
Figura 8: OS Virtualization23
La virtualizzazione in questo caso prevede la creazione di una “zona” o copia del sistema operativo
di base e di uno specifico albero di processi isolato. I processi contenuti in esso non possono afferire a processi esterni ovvero ai processi di altre zone. Si ottiene un ambiente simile ad una macchina
virtuale ma con minore overhead.
Esempi di questo tipo sono SUN Solaris Containers/Zones24, FreeBSD Jails25, Virtuozzo26 e OpenVZ27
23
La figura è tratta dal sito web della società Parallels, http://www.parallels.com/it/products/virtuozzo/os
24
http://www.sun.com/bigadmin/content/zones/index.jsp
25
http://wiki.freebsd.org/Jails
- 17 -
2.2
APPROCCI IMPLEMENTATIVI
Nell’ambito dei diversi VMM, possono essere adottati diversi approcci implementativi che possono essere ricondotti a due grandi famiglie: la virtualizzazione completa e la paravirtualizzazione
2.2.1 VIRTUALIAZZAZIONE COMPLETA
La tecnica della virtualizzazione completa prevede che il VMM mostri alla macchina virtuale tutto
l’hardware necessario all’esecuzione di un sistema operativo tradizionale; il VMM, quindi, tramite
un BIOS virtuale, espone la/le CPU, le memorie, i dispositivi di memorizzazione e così via.
Il vantaggio principale di questo paradigma riguarda la possibilità di eseguire sulle macchine virtuali tutti i tradizionali sistemi operativi senza che questi debbano essere modificati in quanto
l’hardware emulato risulta completamente trasparente.
D’altra parte, le complicazioni derivanti dall’utilizzo di un VMM di questo genere sono una maggiore complessità ed una maggiore dipendenza dal tipo di CPU: quest’ultima, come si capirà meglio proseguendo la lettura, condiziona in modo decisivo sia la stabilità che la complessità del
VMM.
Per capire come funziona un VMM di questo tipo è necessario innanzitutto ricordare che una moderna CPU funziona su almeno due livelli di privilegio (ring): uno denominato supervisore (o anche ring 0) e l’altro (o gli altri) denominato utente; normalmente all’interno del primo anello viene
eseguito il sistema operativo (kernel e moduli/driver), mentre nel secondo vengono eseguiti gli applicativi; all’interno del livello supervisore è ammessa l’esecuzione di tutte le istruzioni della CPU
(privilegiate e non) mentre a livello utente è possibile la sola esecuzione delle istruzioni non privilegiate. Nel caso in cui un’applicazione utente tenti di eseguire un’istruzione privilegiata la CPU (a
seconda dei tipi) può comportarsi in due modi:
•
ignorare la richiesta di esecuzione;
•
avvisare il sistema operativo tramite una trap: il sistema operativo valuta la richiesta e intraprende le opportune azioni.
Nel caso in cui una CPU sia in grado di intercettare tutte le istruzioni privilegiate viene definita
naturalmente virtualizzabile.
Si intuisce facilmente che una CPU di questo tipo ha un duplice vantaggio sui VMM:
•
maggiore efficienza: le macchine virtuali possono eseguire direttamente il codice sulla CPU
fisica senza alcun overhead da parte del VMM;
•
maggiore stabilità: nel caso in cui una macchina virtuale esegua un’istruzione privilegiata e
quindi potenzialmente dannosa per l’intero sistema, la CPU la interrompe e ne dà notifica al
VMM28 che esegue le opportune azioni.
26
http://www.parallels.com/it/products/virtuozzo/
27
http://wiki.openvz.org/Main_Page
28
In questa discussione, per semplicità, si è assunto che i livelli di protezione della CPU siano solo due e che quindi il
VMM sia una componente del sistema operativo. Le CPU normalmente hanno più di due livelli di protezione ed è
- 18 -
Purtroppo esistono alcune CPU che non sono naturalmente virtualizzabili: in questi casi il VMM
deve prevedere una fase di parsing delle istruzioni da eseguire in modo da poter intercettare quelle
che la CPU nativamente non fa: ad esempio VMware implementa una tecnica chiamata fast binary
translation che consente la traduzione al volo di codice potenzialmente pericoloso permettendone
la notifica al VMM (a scapito di un maggiore overhead).
2.2.2 PARAVIRTUALIZZAZIONE
I VMM paravirtualizzati, a differenza di quelli descritti in precedenza, non emulano l’hardware
della macchina fisica, ma definiscono e implementano un’interfaccia applicativa tra VMM e sistema operativo della macchina virtuale (anche nota come Virtual Hardware API). La conseguenza
primaria di un approccio di questo tipo è che il sistema operativo guest deve essere consapevole di
essere in esecuzione in un ambiente virtuale; ne consegue che un sistema operativo per essere eseguito in un ambiente paravirtualizzato deve essere opportunamente modificato rispetto alla sua versione originale.
Questo paradigma ha quindi lo svantaggio di dover sviluppare il porting di ogni sistema operativo,
ma ha tutta una serie di vantaggi:
•
i VMM sono molto snelli e semplici da realizzare;
•
i VMM sono svincolati da CPU che non siano naturalmente virtualizzabili;
•
l’ambiente paravirtualizzato permette una maggiore interattività tra VMM e sistema operativo guest consentendo una maggior efficienza nella gestione delle risorse condivise (ad esempio nel caso della gestione della paginazione, il VMM può chiedere ai sistemi operativi
guest quali sono le pagine di memoria usate di meno).
Attualmente uno dei progetti più noti orientati alla paravirtualizzazione è XEN29, il prodotto sviluppato dall’Università di Cambridge e rilasciato con licenza opensource: su di esso l’unico sistema operativo di cui è stato fatto il porting completo è Linux (XenoLinux); altri porting (più che
altro sperimentali) sono in corso (ad esempio XenoXP Windows e XenoBSD).
2.3
SUPPORTI HARDWARE
Come descritto nei paragrafi precedenti l’implementazione di un VMM risulta più semplice (e
quindi di conseguenza meno costosa e meno soggetta a bachi) se la piattaforma hardware sottostante (ed in particolare le CPU) prevede in modo nativo una serie di funzioni in grado di agevolare
l’esecuzione del VMM e delle relative macchine virtuali.
quindi pensabile che Sistema Operativo, VMM e Macchina virtuale siano eseguiti in tre livelli gerarchicamente differenti.
29
http://www.xen.org/
- 19 -
Nel corso degli ultimi anni, i due produttori di CPU più noti (Intel e AMD) hanno realizzato un
supporto alla virtualizzazione in termini di estensione dell’Instruction Set e di strutture dati dedicate.
Intel ha sviluppato due supporti hardware chiamati VT-x e VT-i utilizzati rispettivamente nelle architetture a 32 bit (IA-32) e a 64-bit (IPF – Itanium Processor Family).
In particolare VT-x definisce due nuove modalità della CPU dedicate alla virtualizzazione30:
•
VMX root operations, dedicata all’esecuzione del VMM
•
VMX non-root operations, dedicata all’esecuzione delle macchine virtuali
La transizione da una VMX privilegiata ad una non privilegiata è chiamata VM exit, mentre quella
contraria VM entry.
Figura 9: VMX: transizioni di stato31
Tali modalità sono ortogonali alla suddivisione nei quattro livelli di protezione: ciò vuol dire che
all’interno degli stati VMX continuano a valere le stesse regole di protezione con l’importante conseguenza che il sistema operativo della macchina virtuale può essere eseguito normalmente nel
ring-0.
La figura sottostante mostra come sono impiegate le modalità VMX e i livelli di protezione nel caso
in cui il VMM sia integrato in un hypervisor (Hypervisor-Hosted).
30
Virtual Machine Extensions (VMX)
31
La figura è tratta dalla presentazione della Digital Enterprise Group Intel Corporation, Understanding Intel® Virtualization
Technology,
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3088782200fe7/TWAR05015_WinHEC05.ppt
- 20 -
Ring 1-2-3 (VMX non-root)
Ring 0 (VMX non-root)
Ring 0 (VMX root)
Figura 10: VMX e livelli di protezione32
Oltre alle due modalità VMX, l’estensione VT-x prevede l’uso di una struttura dati (una per ogni
macchina virtuale attiva) chiamata VMCS (Virtual Machine Control Structure): le funzioni fondamentali di tale struttura sono la gestione delle transizioni di stato VMX (entry e exit) e la definizione delle azioni da intraprendere nel caso in cui la macchina virtuale esegua determinate istruzioni
(privilegiate e non).
Per quanto riguarda invece il mondo AMD, la tecnologia che implementa l’ausilio hardware alla
virtualizzazione è chiamata SVM33. Essa consente di:
•
ottimizzare il cambio di contesto tra VMM e macchina virtuale e viceversa (world switch);
•
intercettare istruzioni ed eventi delle macchine virtuali passando il controllo al VMM;
•
gestire gli interrupt relativi all’esecuzione delle macchine virtuali;
•
gestire indirizzamenti di memoria separati per le macchine virtuali.
Analogamente alla tecnologia VT-x, SVM introduce la modalità guest dedicata all’esecuzione delle
macchine virtuali; in questa modalità si entra quando il VMM esegue l’istruzione speciale
VMRUN.
Il sistema guest viene eseguito fino a che non si verifica uno di questi eventi:
•
esegue l’istruzione VMMCALL;
•
esegue un’istruzione o scatena un evento per cui il VMM aveva espressamente richiesto
l’interruzione.
In SVM la struttura dati analoga al VMCS si chiama VMCB (Virtual Machine Control Block).
32
Idem.
33
La tecnologia è anche nota con il nome in codice Pacifica.
- 21 -
Figura 11: Supporto hardware in AMD (SVM)
- 22 -
