Windows Server Virtualization: Architettura - parte 3

 

Questo post, come altri che seguiranno sullo stesso argomento, sono basati su documentazione originale del team di sviluppo di Windows Server Virtualization ed in particolare di Jeff Woolsey

 

Affrontiamo oggi l'architettura dei device driver virtuali in Windows Server Virtualization.

 

L’emulazione via software di device fisici comporta generalmente un problema di prestazioni, non è facilmente estensibile e non è scalabile.

L’uso della virtualizzazione in scenari di produzione, e non solo di test, ha determinato una sempre maggiore richiesta di prestazioni per poter eseguire in modo efficiente tutti i workload tipici di un data center moderno.

 

La nuova architettura basata su VSC, VSP e VMBus (driver enlightenment), introdotta in Windows Server Virtualization, è pensata per risolvere i problemi posti dai device emulati e per fornire le basi per ulteriori innovazioni nei prossimi anni.

 

La strada scelta, e presentata in questo articolo, consente di:

· Non apportare modifiche al modello di driver di Windows

· Condividere in modo veloce ed efficiente l’hardware mantenendo, nello stesso tempo, l’isolamento tra le diverse partizioni consentendolo solo dove necessario (Partizioni child – partizione parent)

· Indipendenza dal sistema operativo che consenta il supporto anche di sistemi operativi non Microsoft

 

Vediamo più in dettaglio i diversi componenti dell’architettura e le loro interazioni.

 

Virtualization Service Provider (VSP)

I Virtualization Service Provider sono eseguiti nella partizione Parent, comunicano con i device driver e agiscono da multiplexer, consentendo la condivisione dell’hardware tra molte partizioni Child.

Facciamo un esempio per capire meglio la funzione di questo componente.

In un server fisico con una sola scheda di rete, il VSP nella partizione Parent garantisce che questa scheda sia condivisa in modo sicuro (isolamento del traffico e dell’accesso al device fisico) tra tutte le macchine virtuali in esecuzione. Sono in fase di sviluppo VSP per schede di rete, dischi, sistemi di input, scheda video, ecc…

 

Virtualization Service Client (VSC)

I Virtualization Service Client sono in esecuzione nelle partizioni Child. Il compito di questi compenenti è presentare al sistema operativo, in esecuzione nella macchina virtuale, un device virtuale sintetico e comunicare, attraverso il VMBus, con il corrispettivo VSP in esecuzione nella partizione Parent.

VSC e VSP sono sempre accoppiati.

Esiste un set di VSC per ogni macchina virtuale in esecuzione, mentre si ha un solo insieme di VSP per sistema host.

Chiariamo meglio il concetto di “device virtuale sintetico”: con questo termine si indica un pezzo si software che al posto di emulare, per esempio, una scheda di rete Ethernet DEC/Intel in tutte le sue funzionalità (come avviene in Virtual Server 2005) mostra al sistema operativo un “Microsoft Virtual Network Adapter” (nome non definitivo) o invece di emulare un adattatore SCSI Adaptec 7870 (come in Virtual Server 2005) presenterà al sistema operativo un “Microsoft Virtual SCSI Adapter” (anche questo è un nome non definitivo).

Nessuno dei device sintetici è basato su un device reale ed è quindi possibile incrementare le prestazioni e fornire nuove funzionalità in modo semplice rispetto ad un device fisico.

 

VMBus

Il VMBus è il meccanismo che VSP e VSC usano per comunicare tra loro in un processo di comunicazione inter-partizione.

È implementato come un bus punto a punto, ad alta velocità e residente in memoria.

Detto ciò chiariamo che il VMBus:

· non fornisce emulazione

· non ha alcuna relazione con un bus hardware. I device sintetici si connettono al VMBus in un modo che non ha niente a che vedere con le connessioni USB, SCSI o di altro tipo hardware reale

· non comunica con l’hypervisor: consente solo comunicazioni inter-partizione

 

Questa nuova architettura non significa poter fare a meno del tutto dei device emulati. Ci sono due buone ragioni per questo:

· Ancora non esistono sistemi operativi che hanno inclusi i VSC/VSP (nemmeno Windows Server 2008) quindi l’installazione di qualsiasi sistema operativo fallirebbe, se non ci fosse la possibilità di usare dei device emulati.

· Potrebbe essere necessario installare vecchi sistemi operativi entro cui non è possibile installare i device sintetici (VSC).

 

Se VSC e VSP non sono presenti in nessun sistema operativo attuale (compreso Windows Server 2008) significa che devono essere installati in un qualche momento.

I VSP che, ricordo, risiedono nella partizione Parent, sono installati quanto si installano i componenti di Windows Server Virtualization installando il relativo ruolo in Windows Server 2008 (Full o Server Core).

I VSC sono parte degli “Integration Components” (ICs) che possono essere installati nei sistemi operativi guest in esecuzioni nelle partizioni Child.

Il processo di installazione di questi componenti è molto simile al processo di installazione delle “Virtual Machine Addition” in Virtual Server 2005: dal menù della management console di gestione di Windows Server Virtualization si deve scegliere l’opzione “Install Integration Component” (il nome dell’opzione potrà cambiare prima della versione definitiva).

Viene inserito nella macchina ufficiale un CD virtuale e avviato il processo di installazione automatica al termine del quale è necessario riavviare la macchina virtuale. È ovviamente possibile automatizzare l’installazione degli ICs.

 

Vediamo ora come la nuova architettura di virtualizzazione abbia consentito di migliorare le capacità e le prestazione dell’hardware virtuale.

 

IDE Virtuale

In Virtual Server (e Virtual PC), il sotto sistema IDE emulato limita la dimensione massima dei dischi virtuali a 127GB. In Windows Server Virtualization questo limite è salito a 2TB esattamente come per i dischi SCSI.

In Virtual Server 2005 si è sempre consigliato l’uso di dischi virtuali SCSI per avere migliori prestazioni. In Windows Server Virtualization i dischi virtuali IDE e SCSI, quando sono installati gli Integration Components, hanno prestazioni assolutamente identiche.

 

Viene immediato chiedersi quale sia la necessità di avere dischi virtuali IDE e SCSI se le prestazioni sono uguali. La risposta è che le prestazioni non sono tutto.

 

SCSI Virtuale

Windows Server Virtualization supporta fino a 256 hard disk virtuali per adattatore SCSI virtuale.

 Al momento della scrittura di questo articolo il team di sviluppo non ha ancora deciso in via definitiva il numero massimo di adattatori SCSI che saranno supportati in Windows Server Virtualization.

È certo che il numero minimo di adattatori SCSI supportati sarà due in modo da poter supportare il clustering.

I sistemi operativi guest in cui sarà disponibile il supporto per lo SCSI virtuale sono:

· Windows Server 2008

· Windows Server 2003

· Linux

 

Per tutti i sistemi operativi per cui non saranno disponibili gli adattatori SCSI virtuali (Windows 2000, Windows XP, Windows Vista, …) sarà possibile usare fino a quattro dischi IDE di dimensione massima di 2TB ciascuno.

 

Per oggi ci fermiamo qui.

 

Le precenti puntate di questo serie le trovate a questi link:

 

Windows Server Virtualization: Architettura - parte 1

Windows Server Virtualization: Architettura - parte 2

Windows Server Virtualization: Obiettivi di sviluppo

Windows Server Virtualization: Glossario

Giorgio

Comments

• Anonymous
  January 01, 2003
  Qualche tempo fa avevo fatto un post su come installare gli Integration Component di Hyper-V Beta1 in

• Anonymous
  January 01, 2003
  Technorati Tags: Microsoft , Windows , Virtualization , Hyper-V Ultimamente è nato in rete un dibattito

• Anonymous
  January 01, 2003
  Technorati Tags: Microsoft , Windows , Virtualization , Hyper-V Rieccoci, dopo un lungo e desiderato

• Anonymous
  January 01, 2003
  Finalmente sono riuscito a scrivere il quinto e ultimo post dedicato all'architettura di Windows Server