Kernel-Based Virtual Machine

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Sistemi Operativi Kernel-Based Virtual Machine Anno Accademico 2013/2014 Candidato: Luigi Gallo matr. N

2

3 Indice Indice... III Introduzione... 4 Capitolo 1: Introduzione alla Virtualizzazione Tecniche di Virtualizzazione Estensioni di Virtualizzazione per architetture x Capitolo 2: Kernel-Based Virtual Machine Architettura Generale KVM: gestione della memoria Richiami di gestione della memoria Virtualizzazione della memoria in KVM Traduzione da indirizzo guest ad indirizzo host Extended Page Tables e Rapid Virtualization Indexing MMU Notifiers KVM: gestione dell Input/Output Richiami di gestione dell Input/Output Input/Output Para-virtualizzato Input/Output con hardware assistance Altre funzionalità di KVM Capitolo 3: Virt-IO VirtIO: cenni implementativi Conclusioni Bibliografia... 32

4 Introduzione Grazie alla diffusione di hardware sempre più potente, in grado di far eseguire più sistemi operativi in maniera concorrente, si diffondono di conseguenza le tecnologie software in grado di sfruttarlo a pieno. Tra queste vi è la Virtualizzazione. In questo elaborato di tesi verrà presentato uno dei progetti liberi più diffusi nel campo della virtualizzazione: Kernel-Based Virtual Machine (KVM). In un breve capitolo introduttivo saranno discussi prima i concetti di base della virtualizzazione, soffermandoci sulle differenze tra le varie tecniche esistenti e su ciò che ha permesso lo sviluppo di KVM; successivamente passeremo alla trattazione specifica di KVM: i principi basilari, la sua architettura generale, come si propone di gestire la memoria delle macchine virtuali, come si propone di gestire le operazioni Input/Output, ed alcune delle funzionalità secondarie. La trattazione si chiude con la presentazione di VirtIO: sistema supportato da KVM per l I/O Virtualization, 4

5 Capitolo 1: Introduzione alla Virtualizzazione Utilizzare un sistema informatico per emularne un altro similare, è l idea che è alla base della Virtualizzazione. La Virtualizzazione ha origini ben radicate, ed esiste quasi da quando esistono i computer: si è capito da subito che in questo modo si sarebbe potuto svolgere in maniera più sicura, o migliore, molte operazioni che eseguono i computer generalmente. Questo ci è testimoniato dal documento scientifico "Survey of Virtual Machine Research" di Goldberg del 1974 [1], il quale già allora esprimeva le potenzialità di questa tecnica e prevedeva alcuni sviluppi che negli anni a venire effettivamente sono stati realizzati. Tecnicamente, per Virtualizzazione si intende l astrazione delle risorse hardware di un calcolatore costruendo in questo modo una Macchina Virtuale sulla quale è possibile istallare ed eseguire Sistemi Operativi ed altro software. Come prima peculiarità di questo tipo di tecnologie vi è la possibilità di utilizzare più macchine virtuali sulla stessa macchina fisica. Ognuna di esse avrà il suo ambiente operativo separato dagli altri, agendo così in totale sicurezza. L hardware effettivamente necessario è dunque utilizzato a pieno: si riducono costi di acquisto e di alimentazione. Figura 1: virtualizzazione delle risorse 5

6 I vantaggi apportati dall utilizzo di questo tipo di tecnologie sono innumerevoli, sia per architetture desktop, e ancor di più per architetture Server: di solito, per ragioni di sicurezza, si riteneva opportuno eseguire una singola applicazione su una singola macchina fisica. La trasformazione Physical-to-Virtual (P2V) ha stravolto queste credenze, abbattendo il sovradimensionando dei server e portando a grosse riduzioni di costi. La Virtualizzazione è ritenuta vantaggiosa anche in fase di sviluppo e debugging: ispezionare, controllare e configurare una macchina virtuale è molto più semplice in confronto alle macchine fisiche. Anche in fase di testing vi è maggiore comodità, in quanto eventuali errori riscontrati non inficiano sull integrità delle altre macchine virtuali e del sistema ospitante. La portabilità e la duplicazione di macchine virtuali, infine, ci permettono di migrarle su un altra macchina ospitante o di possederne una copia di backup in un certo stato. Il componente centrale di un sistema basato sulla virtualizzazione è l Hypervisor. L Hypervisor, o Virtual Machine Monitor (VMM), ha il compito di gestire la coesistenza di una o più macchine virtuali sulla stessa macchina fisica; il suo operato deve essere trasparente alle macchine virtuali e soprattutto non deve aggiungere eccessivo overhead alle operazioni, in modo da non pesare sulle prestazioni dell intero sistema. 1.1 Tecniche di Virtualizzazione La virtualizzazione può essere implementata utilizzando una delle seguenti tre tecniche: Full-Virtualization, Para-Virtualization, Hardware-Assisted Virtualization. [2] Esse differiscono profondamente tra loro, e in linea di principio non si può dire quale sia la migliore in quanto le prestazioni dipendono fortemente dal tipo di carico di lavoro e quindi dalla particolare applicazione in cui vengono utilizzate. La Full-Virtualization è la tecnica di virtualizzazione attualmente più diffusa, compatibile 6

7 con tutti i sistemi operativi. Esegue il codice utente direttamente sulla CPU fisica, ed effettua una traduzione binaria di quelle istruzioni non virtualizzabili del kernel con altre che hanno l effetto desiderato sull Hardware virtuale. Il Virtual Machine Monitor provvede a fornire ad ogni macchina virtuale tutti i servizi di un sistema fisico, quali BIOS virtuale, dispositivi virtuali, gestione della memoria virtuale. Questa tecnica consente di disaccoppiare completamente il sistema operativo Guest dall Hardware fisico, in modo da tenerlo completamente allo scuro della virtualizzazione sottostante. Non è richiesta, per questo motivo, alcuna modifica ai sistemi operativi Guest. La Para-Virtualization invece risolve le criticità della virtualizzazione modificando il Kernel del sistema operativo. Sostituisce le istruzioni non virtualizzabili del Kernel, con Hypercall che comunicano con l Hypervisor. Vi sono apposite API che risolvono i problemi di gestione della memoria, gestione dell I/O e gestione delle interrupt. Questa tecnica è meno diffusa rispetto alla Full-virtualization perché produce un guadagno in prestazioni solo in alcuni ambiti e per alcuni carichi di lavoro; inoltre soffre di una scarsa compatibilità con alcuni sistemi operativi. La Hardware-Assisted Virtualization, infine, è la più moderna delle tre ed è quella che approfondiremo maggiormente poiché è strettamente correlata a KVM. Questa tecnica già da adesso tiene testa alla più collaudata Full-Virtualization, ma si pensa che per il futuro possa sostituirla completamente. 1.2 Estensioni di Virtualizzazione per architetture x86 Ciò che ha permesso lo sviluppo di KVM è stato, da parte dei fornitori dei processori con architetture x86 (e.g., Intel, AMD), l aggiunta delle estensioni di virtualizzazione all instruction set. Senza di esse è noto come fosse difficile la virtualizzazione con hardware x86, e proprio per l importanza che essa sta acquisendo negli ultimi anni, Intel e AMD hanno lavorato in questo senso. Tali estensioni prendono il nome di Intel VT-x e AMD-V, e sono in dotazione a tutti i 7

8 processori di ultima generazione. Questo nuovo instruction set ha di fatto aggiunto alle già esistenti Kernel Mode e User Mode, la Guest Mode: una modalità operativa del processore con tutti i normali privilegi. Codice proveniente da macchine virtuali, che sia codice di applicazioni o codice privilegiato, esegue in questa particolare modalità. La particolarità è che il software di sistema può richiedere di bloccare selettivamente delle istruzioni o l accesso a particolari registri. Quando vi è uno switch verso la Guest Mode, o di ritorno dalla Guest Mode, avviene un cambio nei registri di controllo, tra cui l instruction pointer. Inoltre quando per mezzo di uno switch si esce dalla Guest Mode, l hardware tramite un report segnala il motivo di questo switch. A raccogliere questa segnalazione vi è l Hypervisor, che esegue in Kernel Mode, e può intraprendere le azioni necessarie per permettere l eventuale ripresa della Guest Mode. In questo modo non c è necessità di tradurre codice, e si risolvono a livello Hardware alcune problematiche della Virtualizzazione, semplificando dunque i Virtual Machine Monitor. Ne consegue un guadagno in prestazioni. Il supporto Hardware fornito da queste estensioni, come vedremo nel prossimo capitolo, è di estrema utilità per i Virtual Machine Monitor anche per la gestione della memoria e la gestione dell I/O. KVM dunque esegue una virtualizzazione completa, servendosi fortemente dell assistenza dell Hardware. 8

9 Capitolo 2: Kernel-Based Virtual Machine Kernel-based Virtual Machine (KVM) è una soluzione oper source alla virtualizzazione, che aggiunge un Hypervisor perfettamente integrato nel kernel Linux. Permette la creazione e l esecuzione di una o più macchine virtuali che si integrano perfettamente con il resto del sistema, e vengono viste come normali processi Linux. L idea di base è di far eseguire codice proveniente da macchine virtuali direttamente sulla CPU fisica. KVM necessita inoltre di un emulatore QEMU (Quick EMUlator), in versione modificata, il quale si preoccupa dell effettiva costruzione della macchina virtuale. 2.1 Architettura Generale KVM si compone di un modulo kernel di base kvm.ko, che fornisce l infrastruttura principale alla virtualizzazione; inoltre, è dotato di altri due moduli specifici, kvm-intel.ko in riferimento all estensioni di virtualizzazione fornite da Intel, e kvm-amd.ko per quelle di AMD. [3] KVM gode di un ampia compatibilità con l hardware, e di una grossa robustezza, derivante proprio dal fatto che utilizza a pieno i moduli di un sistema ben collaudato quale è il kernel Linux. Nell sviluppo di KVM, ci si è concentrati molto più sulle criticità dell hypervisor, delegando al sistema operativo Linux e all Hardware il lavoro sporco (e.g. scheduling, I/O). Questo tipo di approccio si crede possa essere la forza di questo prodotto open source che 9

10 rischia di affermarsi anche a dispetto di piattaforme proprietarie. KVM è strutturato come un tipico device a caratteri in Linux: il suo device node è /dev/kvm, e viene utilizzato per creare ed eseguire macchine virtuali tramite l utilizzo di system call di input/output control, ioctl(). Le operazioni messe a disposizione sono: creazione di una macchina virtuale; allocazione di memoria per una macchina virtuale; lettura e scrittura di registri di CPU virtuale; iniezione di una interrupt in una CPU virtuale; esecuzione di una CPU virtuale. L esecuzione di una CPU virtuale richiede di fatto l utilizzo della Guest Mode. Figura 2: ciclo Guest mode [3] 10

11 Come mostrato in figura, l esecuzione Guest avviene in un ciclo passando per le tre modalità User, Kernel e poi Guest: al livello più esterno vi è la chiamata di una system call affinchè si possa eseguire codice Guest. L esecuzione si arresterà solo a causa di eventuali istruzioni di I/O, o per altri eventi esterni quali l arrivo di pacchetti di rete o altri tipi di interrupt. A livello Kernel invece si forza il processore ad entrare in Guest Mode, con la quale si esegue codice proveniente da macchine virtuali. In seguito, all uscita dalla Guest Mode, si eseguono le operazione necessarie alla ripresa dell esecuzione; queste dipendono ovviamente dalla motivazione per cui si è usciti dalla Guest Mode. 2.2 KVM: gestione della memoria La memoria centrale è uno dei componenti più importanti di un calcolatore, e pertanto il suo grado di ottimizzazione pesa molto sulle prestazione di tutto il sistema. Considerazioni analoghe, se non ancora più forti, si possono fare per le macchine virtuali. Per comprendere a pieno come KVM virtualizza la memoria richiamiamo velocemente concetti di gestione della memoria in ambito non virtualizzato Richiami di gestione della memoria Nei moderni sistemi operativi, i programmi utente lavorano con indirizzi logici (virtuali) di memoria, che saranno poi tradotti in indirizzi fisici di memoria con il supporto hardware del Memory Managment Unit (MMU). Il lavoro dell MMU è affiancato dal Translation Lookaside Buffer (TLB), che è una memoria associativa che effettua attività di caching. Linux ha una gestione della memoria paginata, non segmentata, con livelli di paginazione e diverse dimensioni delle pagine, per permettere la portabilità. Il processo è ingabbiato nel suo spazio di indirizzamento: non vede dati/istruzioni di altri processi, dati/istruzioni del sistema operativo e gli intervalli di indirizzi di I/O 11

12 memory-mapped dei dispositivi. L unico modo che hanno per interagire con l esterno è tramite il sistema operativo (e.g. System call, risorse condivise). In questo modo si realizza la protezione delle risorse. I processi possono richiedere l allocazione di spazi di memoria con una system call, e la memoria allocata viene aggiunta nella tabella delle pagine. Quando il processo accede ad uno spazio di memoria, la pagina viene mappata sulla memoria fisica. Il Kernel, per sua necessità, può rimuovere il mapping pagina-mem.fisica in qualunque momento; quando il processo vi farà di nuovo accesso, si scatenerà un errore di Page Fault e bisognerà mappare di nuovo la pagina Virtualizzazione della memoria in KVM Le macchine virtuali di KVM sono viste come normali processi Linux, e dunque per allocare memoria ad una di essa verrà effettuata una classica system call Malloc(). Se per esempio vogliamo che la macchina virtuale abbia una memoria fisica di 1GB, KVM con una Malloc() le allocherà 1GB di spazio in memoria virtuale (intesa come spazio di indirizzi logici). Questo spazio di memoria non verrà mappato in memoria fisica al momento della Malloc(), ma soltanto quando il processo, e cioè la macchina virtuale, vi farà effettivamente accesso. Mostrando le macchine virtuali, al sistema ospitante Linux, come normali processi, si ottiene automaticamente il risultato di disaccoppiare efficacemente gli ambienti operativi delle macchine virtuali. Una macchina virtuale non può accedere a dati/istruzioni delle altre macchine virtuali né del sistema ospitante. La visione della memoria che ha una macchina virtuale è contigua ed esclusiva, come fosse la sua memoria fisica. 12

13 Figura 3: Memory Virtualization [3] Sulle macchine virtuali eseguiranno i sistemi operativi guest, che attueranno le loro attività di gestione della memoria; avranno le loro tabelle delle pagine guest ed i loro indirizzi di memoria guest. Bisogna in qualche modo sincronizzare le attività guest e le attività host, in modo che non si invalidino tra loro Traduzione da indirizzo guest ad indirizzo host In un sistema basato su virtualizzazione, in aggiunta alla traduzione da indirizzo virtuale a indirizzo fisico, deve essere eseguita la traduzione da indirizzo guest ad indirizzo host. Se volessimo concatenare semplicemente queste due traduzioni, eseguendole in sequenza ad 13

14 ogni accesso in memoria, riscontreremmo grossi cali di prestazioni. Inoltre, in questo modo il sistema operativo guest dovrebbe poter accedere alla tabella delle pagine acceduta dall Hardware fisico, violando così il principio per cui le macchine virtuali sono totalmente disaccoppiate da esso. La tecnica di base utilizzata da KVM è quella tipica dei più comuni sistemi basati su virtualizzazione: la Shadow Page Tables. La tabella delle pagine utilizzata dall hardware è separata da quelle utilizzate dalle macchie virtuali. Quando un guest KVM effettua un cambiamento nella sua tabella delle pagine, l host dovrà prontamente accorgersi di ciò, e a sua volta replicare il cambiamento nella reale tabella delle pagine acceduta dall hardware. KVM è in grado di bloccare l esecuzione della guest mode, quando il guest prova a settare il registro CR3 che punta alla tabella delle pagine, grazie alle estensioni hardware messe a disposizione dal processore. Ogni modifica di una entry nella guest page table, o l inserimento di una nuova entry, viene intercettata da KVM che replica la modifica nella reale tabella delle pagine. In linea di principio questo meccanismo funziona bene perché si evita di eseguire la duplice traduzione, e può coesistere perfettamente con tutte le operazioni di gestione della memoria eseguite dal sistema guest (per esempio i page fault). [4] Figura 4: Shadow Page Tables [5] 14

15 Nasce, però, l esigenza di tenere sincronizzate le tabelle delle pagine guest e la shadow page table: ogni modifica nella guest page table richiede più accessi in memoria, oltre che ulteriore overhead introdotto dalla necessità di bloccare l esecuzione guest ogni volta. Ovviamente il problema si aggrava ulteriormente se pensiamo alla situazione in cui coesistono più macchine virtuali, ognuna con le proprie CPU virtuali. Il mantenimento di questa sincronizzazione costa un calo di prestazioni non trascurabile. Per questo motivo lo sviluppo di KVM è andato avanti, per aggiungere la compatibilità con le nuove estensioni Hardware per una gestione della memoria più efficiente Extended Page Tables e Rapid Virtualization Indexing Per sovvertire a questo grosso calo di prestazioni Intel e AMD hanno proposto le proprie soluzioni, entrambe basate sull idea di effettuare la traduzione da guest physical address a host physical address senza passare attraverso l host page table. Queste estensioni prendono il nome di Extended Page Tables (EPT)(Intel) e Rapid Virtualization Indexing (RVI) (AMD, anche conosciute come Nested Page Tables, NPT). Si permette al sistema operativo guest di gestire gli indirizzi guest, e di effettuare la traduzione da indirizzo guest logico ad indirizzo guest fisico; non vi è alcuna sincronizzazione con la tabella delle pagine host. EPT/RVI entra in gioco quando poi bisogna ottenere l indirizzo host fisico (definito anche machine address). Figura 5: traduzione con EPT [10] 15

16 Non entriamo nel dettaglio di come EPT/RVI effettuano questa traduzione essendo un meccanismo esterno a KVM, ma ci interessa il principio di funzionamento di base e quanto possa migliorare le prestazioni. Per eseguire velocemente questa traduzione è stato definito un insieme di strutture riconosciute dall hardware: ci si affida ad un TLB più grande per tenere traccia anche delle traduzioni richieste direttamente dalle macchine virtuali. Potranno tranquillamente coesistere in questo super TLB voci provenienti da macchine virtuali diverse, identificate con dei tag specifici della macchina virtuale. Figura 6: EPT/NPT Questo meccanismo soffre molto i TLB miss, i quali per essere risolti richiedono un numero considerevole di accessi in memoria, e per questo è necessario un TLB abbastanza grande per ridurli al minimo. Con questa tecnica, KVM è esonerato dal compito di tradurre gli indirizzi guest: secondo Intel le prestazioni possono migliorare addirittura del 48% [5]. 16

17 2.2.5 MMU Notifiers Sia che trattasi di Shadow Page Tables o di EPT/RVI, abbiamo in qualche modo visto come KVM può sincronizzare la gestione della memoria del sistema ospitante a valle di una modifica nella memoria virtuale del sistema Guest. Cosa accade invece se la modifica nativa avviene nell host page table, e cioè nella reale memoria acceduta dall Hardware? Sappiamo che i sistemi operativi, ed in particolare Linux, attuano diverse attività di gestione della memoria, a prescindere delle macchine virtuali (e.g. swapping, condivisione di pagine, rilocazione). Queste attività possono invalidare le tabelle delle pagine guest (oppure EPT/RVI), causando malfunzionamenti. Si potrebbe, in linea di principio, pensare di evitare il problema settando come pinned le pagine di memoria delle macchine virtuali sulla memoria fisica; cioè impedire, bloccare, le operazioni di swapping su queste pagine. In questo modo staremmo in pratica impedendo a tutta la gestione della memoria di usufruire dei grossi vantaggi della paginazione. Una forzatura decisamente eccessiva. MMU_Notifiers è la soluzione adottata da KVM per questo problema: ogni volta che attività specifiche di gestione della memoria centrale riguardano spostamenti di pagine di macchine virtuali, il kernel con una chiamata a mmu_notifier invalidate_page() invaliderà la particolare entry nella guest page table (o struttura EPT/RVI). Sarebbe come notificare la macchina virtuale dell operazione. Successivamente, quando il Guest tenterà l accesso a queste aree di memoria, si bloccherà in un page fault, che sarà risolto nelle normali modalità. Esistono altre funzioni mmu notifier, ognuna per ogni particolare esigenza di gestione della memoria; per esempio nel momento dell allocazione di una nuova pagina di memoria a vantaggio di una macchina virtuale, vi è la chiamata a mmu_notifier change_pte() che provvede ad inserire la nuova entry nella guest page table (o struttura EPT/RVI). 17

18 2.3 KVM: gestione dell Input/Output La gestione delle operazioni di Input/Output di un sistema virtualizzato è il punto più debole della virtualizzazione e in particolare di KVM. Per mezzo della grossa eterogeneità delle periferiche, e della lentezza delle stesse in confronto alla velocità di esecuzione degli altri componenti (e.g. CPU, memoria), l I/O è causa di cali di prestazioni anche in sistemi non virtualizzati. Con l overhead aggiunto dalla virtualizzazione, per macchine che eseguono molte operazione di I/O (per esempio le macchine server), questo problema può risultare un collo di bottiglia abbastanza critico. Esistono diversi sistemi che virtualizzano l I/O in modo efficiente, ognuno di essi riconducibile ad uno dei seguenti tipi: Emulation of devices (Software) Para-virtualization (Software) Hardware Assistance Richiami di gestione dell Input/Output La maggiore parte dei dispositivi di I/O sono estremamente lenti se comparati alla memoria centrale. E necessario dunque mettere a punto tecniche che impediscono alle operazioni di I/O di inficiare le prestazioni del sistema. Rendere efficiente l I/O significa rendere efficiente anche le altre componenti del sistema. Le tecniche di riferimento sono: I/O programmato: il processo attende il completamento dell operazione di I/O; I/O Interrupt-driven: il processo invoca un comando di I/O e si sospende, in modo da liberare la CPU. Quando l operazione è terminata il modulo di I/O invia un interrupt. Direct Memory Access (DMA): il sistema operativo invia al DMA la richiesta di 18

19 I/O, con l indirizzo del dispositivo e altre informazioni necessarie. Completato il trasferimento, il DMA invia un interrupt alla CPU. Ogni periferica necessita di essere configurata prima dell utilizzo; tutto il codice che dipende dal dispositivo viene gestito dal driver del dispositivo. Il compito di un driver è di accettare le richieste provenienti dal device-indipendent software e di controllare che queste siano eseguite Schema di base di KVM Figura 7: KVM, schema di I/O virtualization Le richieste di Input/Output possono avere diversa natura (e.g. Programmed I/O, Memory- Mapped I/O), ognuna di esse con la propria complessità nell essere virtualizzate. 19

20 Il compito di KVM quando trattasi di gestione dell Input/Output è quello di intercettare le richieste di I/O da parte del Guest OS, risolverle, ed emulare il comportamento dei dispositivi. Trattasi infatti di Emulation of devices I/O Virtualization. Dal lato Host, deve permettere l iniezione di interruzioni nel sistema Guest. KVM, per la risoluzione delle richieste di I/O necessita di uscire dalla guest mode. Tutte le richieste di Input/Output vengono inoltrate allo userspace, ed eventualmente si innesca una reale operazione di Input/Output (per esempio il trasferimento di un pacchetto di rete). Al completamento dell operazione vi sono meccanismi per iniettare l interruzione nel sistema guest. Esistono particolari flag che segnalano quando il guest è pronto a ricevere l interruzione. Non è molto diffuso nel dettaglio come KVM risolva queste problematiche poiché spesso si affiancano a KVM sistemi dedicati esclusivamente all I/O, più sofisticati e nettamente più efficienti (e.g. Virtio, capitolo 3) Input/Output Para-virtualizzato Un altro approccio che può essere utilizzato per le operazioni di Input/Output può essere quello della Para-virtualizzazione. Le richieste di I/O da parte delle applicazioni che eseguono nel sistema guest arrivano come di consueto ai driver guest; essi saranno delle versioni modificate che invocheranno a loro volta, con le Hypercall, l intervento dell Hypervisor. Utilizzando questo approccio, il Virtual Machine Monitor non si deve preoccupare di intercettare le richieste di I/O, e di emulare il comportamento dell hardware, ma esse giungeranno autonomamente con la cooperazione dei driver. 20

21 Figura 8: I/O Para-virtualization Questo non è un banale risultato ottenuto, poiché alcune operazione di I/O, per esempio il Memory-Mapped I/O, utilizza le stesse istruzioni di un normale accesso in memoria. C era quindi prima la difficoltà di riconoscere queste richieste e poi di virtualizzarle; il problema non era di facile risoluzione. La gestione delle richieste di I/O è uno degli ambiti in cui la Paravirtualizzazione può funzionare meglio della Full-Virtualization. Questa combinazione di Full-Virtualization con I/O Paravirtualizzato a volte viene definita Hybrid Virtualization Input/Output con hardware assistance Per quanto riguarda l Hardware assisted I/O virtualization facciamo riferimento ad architetture Intel. 21

22 Intel Virtualization Technology for Directed I / O (VT-d) è una ulteriore estensione delle tecnologie di virtualizzazione (VT-x) fornite da Intel, e riguarda prettamente la virtualizzazione dell I/O. Intel VT-d migliora la sicurezza, l affidabilità e le prestazioni dei dispositivi di I/O in ambiente virtualizzato, spingendo ancora oltre la virtualizzazione nella sua missione di riduzione di costi e velocità produttiva[n]. Questa nuova tecnologia è implementata in Hardware, e consiste nell aggiunta di un DMA-remapping che si trova tra il DMA delle periferiche e la memoria fisica. Questo nuovo componente ha il compito di far comunicare i dispositivi di I/O direttamente con le macchine virtuali, in modo che il VMM non viene invocato ad ogni richiesta di I/O. Intel VT-d consente al software di sistema di creare domini di protezione in memoria fisica, che possono rappresentare memoria allocata ad una macchina virtuale oppure allocata da un driver del sistema guest. I dispositivi di I/O vengono assegnati a particolari domini di protezione, e ciò fornisce l isolamento necessario a garantire la protezione delle risorse di ogni macchina virtuale. Quando un dispositivo tenta di accedere ad una particolare locazione di memoria, il DMAremapping verifica se il dispositivo è autorizzato ad accedere al particolare dominio protetto; se non è autorizzato viene segnalato un errore al software di sistema. Figura 9: DMA-remapping [8] In questo modello i dispositivi di I/O sono assegnati direttamente alle macchine virtuali, e 22

23 perciò possono comunicarci in maniera diretta. Quando vi è una richiesta di I/O da parte di un driver del sistema guest non vi è l invocazione del VMM. Il VMM esegue solo attività di controllo al momento dell assegnazione del dispositivo alla particolare macchina virtuale. E il driver del sistema guest a controllare il dispositivo. Sappiamo però che il sistema operativo guest lavora con indirizzi guest, che saranno poi tradotti in indirizzi host. Nasce dunque l esigenza di eseguire questa conversione, ed è il principale compito del DMAremapping (da cui il nome rimappatura ). Il DMA-remapping è programmato dal VMM, che conosce le corrispondenze GPA-HPA (indirizzo guest indirizzo host), in modo che i dati vengano trasferiti direttamente sul buffer appropriato del guest. Non vi è alcuna attività di emulazione da parte del VMM né alcuna modifica nei driver del sistema guest.[8] Figura 10: assegnazione diretta del dispositivo [8] 2.4 Altre funzionalità di KVM KVM supporta molte funzionalità desiderabili nell ambito della virtualizzazione. 23

24 Uno dei motivi per cui la virtualizzazione ha preso piede nell informatica moderna è la possibilità di migrare le macchine virtuali su un altro sistema host: Live Migration. KVM supporta la Live Migration senza interrompere l esecuzione della macchina virtuale durante il trasporto; può essere considerata funzionante e connessa in rete sempre, dato che risulta inattiva solo per poche decine di millisecondi. Gli utenti che la utilizzano in maniera remota, non si accorgeranno della rilocazione su un diverso host fisico. La Live Migration funziona copiando Figura 11: Live migration [6] la memoria del guest sull host d arrivo della migrazione, in parallelo con l esecuzione del guest ancora sull host di partenza; se una pagina di memoria viene modificata dopo la sua copia sull host d arrivo, essa dovrà essere ricopiata. A questo proposito, KVM fornisce un dirty page log per tener traccia delle pagine di memoria da ricopiare. La Live Migration è utilizzata anche per copiare le macchine virtuali in un certo stato, per possederne copie di buckup su un altro host fisico. KVM supporta anche il Kernel SamePage Merging (KSM): un sistema che permette la condivisione di pagine di memoria tra macchine virtuali. Spesso in memoria vi sono pagine ridondanti per mezzo che ogni copia è riferita ad una singola macchina virtuale. Con KSM si fa uno scanning della memoria delle macchine virtuali, e qualora si trovino pagine identiche ne si fa l unione in una singola pagina condivisa tra due o più macchine virtuali. Se successivamente uno dei guest tenta di modificare una pagina condivisa, otterrà la sua copia privata. KSM è una funzionalità che KVM supporta in quanto facente parte del kernel Linux. VirtIO mette a disposizione di KVM un driver specifico per il supporto al ballooning, e cioè i guest KVM possono dinamicamente ridurre o incrementare la dimensione della propria memoria. Questa funzionalità è utile a sostenere l host KVM in caso di 24

25 over-committing della memoria. Supponiamo di avere una macchina virtuale con una memoria di 2GB; se per esempio sta utilizzando soltanto 1GB di memoria, potrebbe essere utile cedere il GB restante all host, in modo che possa assegnarlo ad un altra macchina virtuale oppure farne in ogni caso un utilizzo migliore. Le operazioni principali implementate dal balloon driver sono quindi: Inflate: memoria viene ceduta dal guest all host; Deflate: memoria viene ceduta dall host al guest; Figura 12: ballooning [9] Non è sempre prevedibile come si distribuiscono sulle macchine virtuali i carichi di lavoro, quindi avere la possibilità di concedere memoria aggiuntiva ad una macchina virtuale sotto pressione, a svantaggio di un altra al momento più libera, può aumentare la produttività dell intero sistema. Inizialmente c era il problema che questa gestione dinamica dell assegnazione di memoria doveva essere fatta del tutto manualmente; doveva esserci qualcuno a monitorare la situazione e decidere in che modo effettuare il ballooning. Dato che questa funzionalità deve essere automatica per essere davvero utile, nelle ultime versioni di KVM è stata aggiunta la automatic ballooning: i guest e l host cooperano in 25

26 modo che, se è possibile, nessuno vada sotto pressione con la memoria. Sono definiti tre livelli di pressione della memoria, per ognuno dei quali i guest ritornano all host un certo numero di MB di memoria, in dipendenza al proprio livello di pressione di memoria. [9] Sia per la definizione dei livelli di pressione che per il numero di MB restituiti, ci sono parametri da settare, modificabili anche a run-time. Il tuning di questi parametri è importante per un corretto funzionamento dell automatic ballooning, e dipende fortemente dalla distribuzione dei carichi di lavoro sulle macchine virtuali. La virtualizzazione sta aprendosi strada anche in ambito embedded. I benefici che esso apporta, quali per esempio il semplice speed-up oppure la grossa comodità in fase di sviluppo, debugging e testing, ha aperto il mercato degli hypervisor anche al mondo embedded. Le peculiarità di KVM si incastrano perfettamente con le necessità di questi ambiti: vasta compatibilità con l hardware, possibilità di emulazione di hardware fuori produzione, compatibilità con tutti i sistemi operativi (anche Real Time OS), customizability, semplicità. [11] 26

27 Capitolo 3: Virt-IO VirIO è uno standard di I/O virtualization per dispositivi (e.g. dischi, dispositivi di rete). E la principale piattaforma di I/O Virtualization scelta da KVM per migliorare le prestazioni di rete e le operazioni su disco delle macchine virtuali. VirtIO si basa sul principio della Para-virtualizzazione, e cioè mette a disposizione un insieme di API che permettono la collaborazione dell Hypervisor con i driver modificati del guest, per risolvere in modo efficiente le richieste di I/O delle macchine virtuali. La sua implementazione si colloca in un modulo kernel nel guest, che rappresenta il frontend driver, e in un device di QEMU, che rappresenta il back-end driver. Figura 13: VirtIO, comunicazione guest-host [7] 27

28 Il front-end driver ha il compito di raccogliere le richieste di I/O che arrivano dai processi, e di inviarle al back-end driver. Il back-end driver accetta le richieste provenienti dal front-end driver ed esegue le operazioni di I/O sull hardware fisico. L effettiva comunicazione tra i due driver avviene tramite dei buffer di memoria condivisi tra i guest e QEMU, che VirtIO chiama virtqueue. Ogni operazione di I/O richiede una o più virtqueue per lo scambio dei comandi e per l effettivo trasferimento dei dati. Si crea, in questo modo, un canale di comunicazione diretto tra il guest e l host. [7] Figura 14: schema di I/O virtualization con VirtIO Se confrontiamo lo schema di VirtIO (in figura) e lo schema di base di KVM, notiamo che il flusso di dati giunge all hardware, o dall hardware, in maniera più diretta e veloce. Si 28