Xen paravirtualizzato
Come funziona la paravirtualizzazione in Xen? Ecco una spiegazione semplice sul meccanismo che Xen adopera per mantenere il completo controllo delle macchine virtuale.
Se si vuole adoperare un VMM (virtual machine monitor ossia l’hypervisor in Xen), questo deve agire con maggiori privilegi rispetto alle macchine virtuali poiché deve avere il completo controllo delle risorse tra gli ambienti virtuali.
Generalmente i VMM ricorrono alle tecnica chiamata ring deprivileging (se non sono disponibili delle estensioni per la virtualizzazione), ossia un espediente per far funzionare il software del guest con livello di privilegio superiore a zero (ring > 0). Un sistema operativo guest può essere “deprivileged” in due maniere:
- l’ospite opera in ring 1
- l’ospite lavora con livello di privilegio 3
Se il processore non ha le estensioni per la virtualizzazione, l’hypervisor di Xen opera in kernel mode, mentre il sistema operativo host e il kernel nelle macchine virtuali ha ring 1 e le applicazioni restano nel classico “user mode”.
Spostare il kernel in ring 1 comporta dei problemi, per cui si usa la strategia ring aliasing. Ring aliasing si riferisce al problema che sorge quando un software opera ad un livello di privilegio diverso da quello per cui è stato scritto.
Inoltre è necessario disporre di un kernel in grado di funzionare nel ring 1, per cui gli sviluppatori di Xen hanno dovuto modificare il codice sorgente di Linux per adattarlo al ring 1. Siccome il kernel di Windows non può essere modificato, Windows non è paravirtualizzabile e così come altri sistemi di cui non si dispone di libero accesso ai sorgenti o l’adattamento del sistema non può essere, per svariate ragioni, portato a termine.
Nel caso di Xen è l’hypervisor che media la risorse tra i domini non privilegiati e agisce per procura sull’hardware fisico.
In più usufruendo della paravirtualizzazione, le chiamate di sistema (SYSTEM CALL) così come le hypercall hanno la necessità di far uso di un’istruzione di interrupt software che rende critica la gestione del sistema.
Infatti (come è riportato nella sezione dedicata alle system call), la chiamata di SYSEXIT, che l’istruzione per uscire da una chiamata di sistema, fallisce se eseguita in un livello diverso dall’anello 0. Questa situazione si verifica se un kernel funziona in ring 1, perché SYSEXIT opera in ring 1 invece che zero.
Invece grazie alle estensioni per la virtualizzazione non occorre più che il sistema operativo funzioni a livello 1 perché sono state introdotte delle nuove modalità (root e non root) che consentono all’hypervisor di operare in root mode mentre l’O.S. guest in non root mode ma nel ring0.
