Page 1

2008 Microsoft PierGiorgio Malusardi

{WINDOWS SERVER 2008

HYPER-V}

[Digitare qui il sunto del documento. Di norma è una breve sintesi del contenuto del documento. [Digitare qui il sunto del documento. Di norma è una breve sintesi del contenuto del documento.]

1


2


Introduzione Lo scopo di questo breve articolo è esporre, sinteticamente e in modo chiaro, l’architettura e le funzionalità di Windows Server 2008 Hyper-V. Molte delle che sono trovate in questo documento le ho già esposte, lo scorso anno, in una serie di articoli pubblicati sul mio blog (http://blogs.technet.com/pgmalusardi) e le potete trovare, in lingua inglese e in forme diverse, su diverse fonti, tra cui il la fonte più autorevole: il blog del team di sviluppo di Hyper-V (http://blogs.technet.com/virtualization/default.aspx). Per meglio capirci nel seguito, penso sia una buona idea definire un linguaggio comune e quindi partire da un glossario minimo in modo da allinearci sui termini che userò nei prossimi post. Non voglio certo essere esaustivo: riprenderemo i diversi termini nel tempo approfondendo la loro definizione. Iniziamo con una figura (non in scala; se lo fosse Windows Hypervisor sarebbe più sottile di un pixel).

Hypervisor Un hypervisor è uno strato di software che risiede appena sopra l’hardware a beneficio di uno o più sistemi operativi. Il suo compito principale è fornire ambienti di esecuzione isolati chiamati partizioni (partition). Ogni partizione ha il proprio insieme di risorse hardware (memoria, device, cicli di CPU). Responsabilità dell’hypervisor è controllare e arbitrare l’accesso all’hardware sottostante.

3


Partizioni Una partizione è l’unità base di isolamento supportata dall’hypervisor. Una partizione è costituita da un spazio di indirizzamento e uno o più processori virtuali. In aggiunta, ad ogni partizione, possono essere assegnate risorse hardware specifiche (memoria, device e cicli di CPU) e determinati diritti di accesso e permessi. Le partizioni possono essere di due tipi Parent Partition Una partizione che serve per creare altre partizioni (Child Partition) e contiene lo stack di virtualizzazione per controllarle. Nella prima versione di Hyper-V sarà possibile avere una sola partizione parent per ogni sistema fisico. Child Partition Ogni partizione creata e controllata da una parent partition. Guest Il software in esecuzione in una child partition è definito guest. Un guest può essere un sistema operativo con tutte le funzioni (come Windows Server 2008) o un sistema a kernel ridotto e dedicato a specifiche funzioni. L’hypervisor di Microsoft è agnostico rispetto ai guest. Device emulati (Emulated device ) Device virtuali che riproducono completamente un device fisico realmente esistente. L’interfaccia di accesso all’hardware virtualizzato è indistinguibile dall’interfaccia verso l’analogo device fisico. Device "sintetici" (Synthetic device) Device virtuali che non hanno un corrispettivo nel mondo fisico. Gli stack costruiti sui device sintetici possono usare un bus speciale (il VMBus) per comunicare con device fisici presenti in altre partizioni.

Obiettivi di sviluppo di Hyper-V Nella fase di progettazione di Hyper-V, il team di sviluppo si è posto una serie di obbiettivi chiari e ben definiti. Descriverli con il rigore e la precisione tecnica adeguati richiederebbe molto spazio. Provo, quindi, a darne una visione concisa. SICUREZZA Hyper-V deve fornire un’elevata sicurezza dato che risiede al più basso livello, appena sopra l’hardware. Due principi sono alla base della sicurezza isolamento e minimalismo. Analizziamoli un po’ più in dettaglio. Isolamento

L’hypervisor deve isolare il proprio codice e i propri dati dall’osservazione e dalla modifica da parte di codice in esecuzione in qualsiasi partizione. In aggiunta l’hypervisor deve fornire mutuo isolamento tra le diverse partizioni consentendo a ciascuna l’esecuzione senza interferenza o osservazione da parte di codice in esecuzione nelle altre. Questo include:

4


  

Isolamento dei dati – codice e dati nello spazio di indirizzamento di una partizione non devono essere accessibili alle altre partizioni (a meno di esplicita condivisione). Isolamento temporale – ad una partizione non deve essere possibile “rubare” tempo macchina ad un’altra partizione (per evitare DoS). Isolamento interno – l’hypervisor deve mantenere isolamento interno tra le partizioni (es. differenti pool di memoria per ogni partizione).

Minimalismo. L’hypervisor è eseguito nel più privilegiato possibile dei modi e ha accesso a tutte le risorse della macchina. Minimizzare la quantità di codice che gira in questo contesto è fondamentale da un punto di vista della sicurezza (oltre che delle prestazioni) in quanto in questo modo si riduce la “superficie” esposta a possibili tentativi di attacco. La stretta aderenza al concetto di minimalismo è una delle chiavi di differenziazione dalle soluzioni di altri fornitori. AFFIDABILITA' È evidente che l’uso della virtualizzazione rende l’affidabilità dei sistemi più importante che mai. Lo stack di virtualizzazione e la partizione parent costituiscono un possibile “point of failure” per tutte le partizioni child (ossia: molti server virtuali sono “sostenuti” e funzionano grazie alla strato di virtualizzazione). È imperativo che i componenti di virtualizzazione siano il più affidabili e resistenti possibili ai crash e agli attacchi di sicurezza. Questo significa anche che il sistema operativo in esecuzione nella partizione parent deve essere il più leggero possibile e contenere la minor quantità possibile di codice di terze parti o non collegato alla virtualizzazione (ancora una volta il concetto di minimalismo). Quando si esegue un workload per server fisico, la caduta di quest’ultimo, per un qualsiasi motivo (problemi HW o SW, installazione di patch, …) è un problema, ma ha effetto su un solo servizio (o un numero limitato di servizi). In un ambiente virtuale dove su un unico server fisico sono in esecuzione per esempio 20 server virtuali, la caduta del server fisico ha un impatto su 20 diversi workload. Questo è uno dei motivi, come vedremo, per cui virtualizzazione e clustering viaggiano appaiati. Per aumentare l’affidabilità del sistema sono stati seguiti un paio di concetti chiave: Semplicità Una serie di tecniche e decisioni di architetturali hanno consentito dell’hypervisor.

di rendere

semplice la struttura

Stratificazione Un disegno a livelli sovrapposti è richiesto per ottenere alcune certificazioni di sicurezza (es. EAL-6/EAL-7, i livelli più elevati di certificazione previsti dai Common Criteria) e per garantire una migliore modularità e funzionalità. Hyper-V è stato costruito con un approccio a livelli sovrapposti. Per comprendere meglio i vantaggi che un’architettura a livelli sovrapposti comporta, la si deve confrontare con l’architettura tradizionale degli hypervisor. Prendiamo in considerazione un hypervisor puramente teorico e non basato su alcun prodotto reale, ma utile per il confronto.

5


L’immagine precedente mostra una delle possibili implementazioni di un hypervisor. La cosa importante in questa architettura sono le linee che congiungono i diversi componenti. In un approccio tradizionale, come quello rappresentato, i dati fluiscono da un componente all’altro in una configurazione a matrice. Con questa architettura è molto difficile testare l’affidabilità di un componente che può dialogare con qualsiasi altro, in ogni dato istante. Confrontiamo questo approccio con un’architettura a livelli sovrapposti come quella adottata in Hyper-V.

6


In un disegno di questo tipo i dati possono fluire orizzontalmente o verticalmente, ma non secondo una matrice dove ogni componente può interagire con qualsiasi altro: non ci sono possibili flussi circolari. Se per esempio il Dispatch Manager (Dm) deve comunicare con il gestore dell’indirizzamento (Address manager – Am), il flusso di dati avverrà verso il basso attraverso il gestore delle hypercall (Hypercall handler – Hc), il gestore delle partizioni (Partition Manager – Pm)e il Synthetic Interrupt Controller (SynIC). La cosa importante è che esiste un numero finito e di percorsi che portano da un componente ad un altro qualsiasi, verso l’alto o verso il basso. La lunghezza dei percorsi è deterministica e questo consente di imporre dei limiti temporali precisi ai percorsi di esecuzione dell’hypervisor. Minimalismo Un concetto che ritorna. Per aumentare la semplicità dell’hypervisor è stato deciso di implementarlo come un micro-kernel: tutte le funzionalità che per motivi sicurezza o prestazioni non devono essere necessariamente nell’hypervisor sono state spostate nello stack di virtualizzazione in esecuzione dentro una partizione. Su questo aspetto ci sono almeno due diverse scuole di pensiero. In VMware ESX3/VI3, il codice che emula l’hardware legacy gira nello stesso contesto dell’hypervisor. VMWare dice che in questo modo si guadagnano uno o due punti percentuali nelle prestazioni. Microsoft (e Xen che ha una visione molto simile), in Hyper-V, ha messo quasi tutto il codice di questo tipo nello stack di virtualizzazione, non nell’hypervisor. Poche risorse, strettamente legate alle prestazioni sono implementate direttamente nell’hypervisor (l’APIC virtuale e certi interrupt hardware periodici sono due esempi di questo). Questa modalità di implementazione consente di ridurre la possibile superficie di attacco e rende l'architettura dell'hypervisor più robusta e affidabile. SCALABILITA' Tutti le tecnologie di virtualizzazione (Microsoft e no) presenti oggi sul mercato hanno dei limiti. In alcuni casi questi limiti sono più stringenti e in altri più ampi e consentono maggiore scalabilità, ma il punto è che le tecnologie di virtualizzazione hanno ancora un ampio spazio di evoluzione e maturazione. Esempi di limiti delle attuali tecnologie sono : Virtual Server     

Memoria fisica supportata : 64 GB in VS2005 R2 - 256 GB in VS2005 R2 SP1 su Windows x64 Numero di VM in esecuzione contemporanea: 64 in VS2005 R2 – un numero maggiore in VS2005 R2 SP1 su Windows x64 Un solo processore per VM 3,6 GB di RAM per VM 4 schede di rete virtuali per VM

VMware ESX/VI3

 

Il numero di macchine virtuali eseguite contemporaneamente è limitato a 128 core virtuali: o 128 VM a singolo core o 64 VM dual core o 32 VM a quattro core Memoria virtuale per VM limitata a 64 GB. 4 schede di rete virtuali per VM

7


Compatibilità hardware relativamente limitata

Il team di sviluppo di Hyper-V ha disegnato un’architettura di virtualizzazione che scala facilmente e non richiederà un ridisegno in pochi anni a causa della comparsa sul mercato di nuovo hardware con più core, più capacità di memoria o di rete. Windows Server Virtualization non ha limiti di disegno o ha limiti molto, molto ampi. Due soli dati a sostegno di queste affermazioni:

 

Windows Server Virtualization può scalare fino a 2 terabyte di memoria fisica. Windows ServerVvirtualization non ha limiti sul numero di VM in esecuzione contemporanea. L’unico limite è posto dall’hardware su cui è eseguito.

L’architettura di Virtual Server 2005 Per comprendere meglio l’architettura di Windows Server Virtualization conviene confrontarla con quella di Virtual Server 2005. Una delle difficoltà nello sviluppo di Virtual Server è il fatto che malgrado i decenni di sviluppo dell’architettura x86, questa presenta ancora troppe lacune per poter supportare efficacemente uno strato di virtualizzazione altamente compatibile. COMPATIBILITÀ PER I GUEST Una dei maggiori vincoli posti durante lo sviluppo di Virtual Server 2005 è stata la richiesta di avere un ambiente di virtualizzazione in grado di fornire la massima compatibilità possibile con un ampio spettro di vecchi sistemi operative. Virtual Server è in grado, infatti, di eseguire un gran numero di sistemi operativi: da DOS a Windows Vista, passando per OS/2, Windows 95, Linux ecc… Io personalmente sono riuscito a far girare sistemi operativi un po’ esoterici come BeOS. Tre tecnologie chiavi consentono a Virtual Server di ottenere questi risultati:   

ring compression, patching del sistema operativo guest emulazione dei device.

Sotto trovate un diagramma dell’architettura di Virtual Server 2005 che ci faciliterà nel proseguio del discorso.

8


RING COMPRESSION Concentriamoci sulla parte destra dello schema soprastante ed in particolare la parte indicata con Guest Kernel Mode. Quello che accade è che il sistema operativo installato nella macchina virtuale pensa di essere eseguito a Ring 0 mentre nella realtà è eseguito a Ring 1. La tecnica Ring Compression consiste esattamente in questo. Virtual Server esegue la ring compression in modo da poter eseguire il Virtual Machine Monitor (VMM.sys) al di sotto del sistema operativo guest, in Ring 0. In questo modo VMM.sys è in grado di intercettare le chiamate al “sottostante hardware”. Il ruolo principale di VMM.sys è quello di monitor: risiede tra hardware e sistema operative guest in modo da impedire a quest’ultimo di valicare i confini assegnati. Questa tecnica è un compromesso necessario per far funzionare la virtualizzazione su sistemi che non forniscono supporto hardware alla virtualizzazione. L’avvento del supporto hardware alla virtualizzazione (Intel-VT e AMD-V) ha reso possibile disegnare Hyper-V in modo che non sia più necessario usare la Ring Compression. In questo modo è possibile:   

Semplificare lo strato di virtualizzazione Ridurre i problemi di test e di sviluppo Ridurre la superficie di esposizione

VM ADDITIONS Consideriamo ora un altro componente presente nella parte destra dello schema sovrastante: le Virtual Machine Addition. Le Virtual Machine Addition sono installate nel sistema operativo Guest (Windows o Linux : non sono disponibili per altri sistemi opertivi) e hanno due funzioni:

9


 

Fornire integrazione con il sistema operativo Host (sincronizzazione del tempo, integrazione del puntatore del mouse, hearthbeat del guest,…) Patchare in memoria il sistema operativo Guest per aumentarne le prestazioni

Se avete provato ad accedere ad un sistema operative Guest senza Virtual Machine Addition installate, lo scopo della prima funzione è ovvio. La seconda funzione (modifica in memoria del sistema operativo guest) è tutta correlata alle prestazioni. Le Virtual Machine Addition includono un driver che è caricato a boot time nelle prime fasi del processo di boot. Lo scopo di questo driver è quello di modificare sei istruzioni del sistema operativo guest che sono difficili ed dispendiose, in termini di prestazioni, da emulare. Anche questo è un compromesso legato alla non disponibilità di supporto hardware alla virtualizzazione. Con Hyper-V e la virtualizzazione assistita da hardware non è più necessario eseguire il patching al volo del sistema operativo guest per aumentare le prestazioni. EMULAZIONE DEI DEVICE È il tipo di virtualizzazione dei device in cui l’interfaccia verso i device virtuali è indistinguibile dall’interfaccia verso gli analoghi device fisici. L’emulazione dei device è resa necessaria da una serie di motivi, tra cui:  

Astrarre il sistema operativo Guest dal reale hardware fisico Fornire un metodo per la condivisione di diversi device fisici (es. dischi e rete) tra diversi sistemi operativi

Il team di sviluppo ha deciso di emulare una serie di device fisici specifici in modo da essere ragionevolmente sicuri che i sistemi operativi Guest avessero i driver necessari per supportare l’hardware virtuale. Alcuni dei device emulati sono:    

Piastra madre Intel 440 BX Scheda di rete DEC/Intel 21140 Scheda grafica S3 Trio con 4MB di RAM video Scheda SCSI Adaptec 7870

La tecnica di emulazione dei device ha permesso di ottenere un’elevata compatibilità con un numero elevato di sistemi operativi, ma presenta dei pro e dei contro: 

Pro: Compatibilità: Il maggior beneficio dell’emulazione di device è l’estesa compatibilità all’indietro. La compatibilità con più di mille sistemi operativi è sicuramente una cosa importante (ATTENZIONE: compatibilità non significa supporto da parte di Microsoft) Contro: Prestazioni: Il prezzo che si paga con l’emulazione dei device è un sovraccarico che penalizza le prestazioni.

Ora abbiamo gli elementi base dell’architettura di Virtual Server che ci consentiranno di fare dei confronti con l’architettura di Hyper-V.

L’architettura di Hyper-V Dopo aver visto l’architettura di Virtual Server 2005 abbiamo ora le basi per poter vedere quella di Windows Server Virtualization evidenziando le differenze.

10


NO RING COMPRESSION Mentre in Virtual Server 2005 la ring compression era una tecnica fondamentale per rendere possibile la virtualizzazione, in Hyper-V questa tecnica non è necessaria e non è stata usata. Guardiamo il diagramma sottostante. È da notare la presenza e l’uso di tre diversi ring di processore: Ring 3 (User mode), Ring 0 (Kernel mode) e un nuovo “Ring -1.” Il “Ring-1” rappresenta una delle principali novità introdotte dalla virtualizzazione assistita da hardware: l’aggiunta di nuovi ring alla piattaforma hardware per facilitare la virtualizzazione. Questo significa che non è più necessario comprime un sistema operativo in “Ring 1” per poter inserire codice al di sotto, semplicemente si usa un nuovo ring che risiede sotto il ring di esecuzione del sistema operativo: in questo nuovo ring è eseguito l’hypervisor

NESSUNA PATCH PER I GUEST Un altro beneficio dell’esecuzione del sistema operativo guest in Ring 0 (nella modalità per cui è stato disegnato) è un incremento delle prestazioni senza nessuna modifica: non è più necessario usare delle patch (VMAddition) per aumentare le prestazioni del sistema operative guest. WINDOWS HYPERVISOR Un altro aspetto da notare nel diagramma sovrastante è la presenza di Windows hypervisor. Questo è l’elemento completamente nuovo. In Virtual Server il Virtual Machine Monitor gira in Windows (questa viene chiamata virtualizzazione hosted). Con Hyper-V, l’hypervisor gira “sul metallo”: questa è chiamata virtualizzazione hypervisor-based.

11


L’hypervisor è un componente che viene installato solo quando si decide di installare il ruolo server Hyper-V, non è presente per default nelle installazioni di Windows Server 2008. PARTIZIONE PARENT La partizione Parent agisce come proprietario di default di tutte le risorse hardware. Tra i suoi compiti ci sono il power management, la gestione del plug and play e degli eventi legati agli errori hardware. Questa partizione è anche responsabile della creazione e della gestione delle altre partizioni e dell’assegnazione delle risorse hardware. Entriamo in maggiore dettaglio nelle funzioni della partizione Parent. I driver risiedono nella partizione Parent Una domanda frequente che è posta quando si parla di Hyper-V è: “Dove devo installare i driver della mia scheda fiber channel, della mia scheda video, del mio adattatore di rete, ecc?” I driver dei componenti hardware del sistema sono installati nella partizione Parent (sono indicati nel diagramma sovrastante come “Driver”). Questi sono normali driver standard per Windows, non driver speciali per la virtualizzazione. Il fatto che Hyper-V non richieda driver speciali è fondamentale se consideriamo le migliaia di driver disponibile per Windows. Nessun driver per l’hardware del sistema fisico host è eseguito nelle partizioni Child. Le macchine virtuali presentano al sistema operativo guest dei device virtualizzati in forma di device emulati o di device sintetici. Torneremo a breve sull’argomento device driver. Gestione remota di Windows Server Virtualization via interfaccia WMI nella partizione Parent Hyper-V espone delle API WMI per creare, gestire, controllare, configurare le risorse virtuali (“WMI” nel diagramma sovrastante). È possibile trovare l’elenco completo delle API con la loro descrizione formale ed esempi d’uso a questo link: http://msdn.microsoft.com/en-us/library/cc136992(VS.85).aspx Ci si aspetta che API WMI di Hyper-V vengano diffusamente usate in una serie di differenti scenari:   

Da vendor di sistemi di gestione che vogliano scrivere tool per la gestione di Hyper-V. Un esempio è Citrix XenDesktop Da grandi aziende che vogliano costruire i loro tool interni di gestione degli ambienti virtualizzati Sviluppatori che vogliano automatizzare la virtualizzazione di ambienti di sviluppo/test usando script

IMPORTANTE Le API WMI sono il metodo preferenziale per gestire programmaticamente Hyper-V. Da quanto detto fin’ora sulla partizione Parent è evidente che questa costituisca un single point of failure. Effettivamente la perdita di funzionalità della partizione Parent per spegnimenti pianificati (manutenzione, applicazione di patch) o non pianificati (problemi hardware o di alimentazione, per es.) determina la perdita di tutte le macchine virtuali. Questo fatto rende ancora più evidente l’importanza di un punto rimarcato sin dall’uscita di Virtual Server 2005 R2: alta disponibilità e virtualizzazione devono viaggiare appaiati. Con Hyper-V l’utilizzo del servizio di Microsoft Cluster Service, integrato in un’installazione Server Core di Windows Server 2008, è molto più semplice di quanto non sia oggi con Virtual Server 2005 R2; è infatti

12


possibile creare macchine virtuali in cluster direttamente dall’interfaccia di amministrazione di Microsoft Failover Cluster Service o da System Center Virtual Machine Manager 2008. I due consigli più importanti relativi all’implementazione di Hyper-V sono: 1. 2.

Eseguire Hyper-V in un’installazione Server Core di Windows Server 2008 Mettere in cluster gli host fisici

Un’altra obbiezione che può essere fatta riguardo la partizione Parent è che questa sembra molto simile al sistema operative host di Virtual Server (e di Virtual PC). Effettivamente la partizione Parent fa alcune delle cose che sono fatte dal sistema operativo host di Virtual Server. La cosa che deve essere chiara è che Hyper-V non è virtualizzazione hosted, ma hypervisor-based e la differenza tra le due è sostanziale, come ho cercato di evidenziare fino ad ora. La partizione parent è il “luogo” dove vengono eseguiti i device driver per i dispositivi hardware. Questa scelta è stata fatta per evitare che codice di terze parti fosse eseguito nell’hypervisor e per non determinare un eccessiva crescita delle dimensioni di questo con importanti ricadute negative su sicurezza e prestazioni. Windows Server Virtualization può essere eseguito indifferentemente con un’installazione full o con un’installazione Server Core di Windows Server 2008 Pur potendo usare entrambe le modalità di installazione di Windows Server 2008 è consigliato l’utilizzo della modalità Server Core per ridurre la quantità di risorse usate dalla partizione Parent e per ridurre la superficie di possibile attacco.

I device virtuali di Hyper-V 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 Virtual Service Client (VSC), Virtual Service Provider (VSP) e VMBus (driver enlightenment), introdotta in Hyper-V, è pensata per risolvere i problemi posti dai device emulati e per fornire le basi per ulteriori innovazioni nei prossimi anni. La strada scelta, 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.

13


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. Esistono 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 componenti è 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. 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 Machine Bus Network Adapter” o invece di emulare un adattatore SCSI Adaptec 7870 (come in Virtual Server 2005) presenterà al sistema operativo un “Microsoft Virtual Machine Bus SCSI Adapter”. Nessuno dei device sintetici è basato su un device fisico 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 interpartizione. È implementato come un bus punto a punto, ad alta velocità e residente in memoria. Esiste un VMBus per ogni partizione child in modo da isolare le comunicazioni tra le partizioni child e la partizione parent. 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 HyperV installando il relativo ruolo in Windows Server 2008 (Full o Server Core). I VSC sono parte degli “Integration Service” (IS) 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 Hyper-V si deve scegliere l’opzione “Insert Integrations Services Setup Disk”. In questo modo è 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 IS.

14


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 Hyper-V questo limite è salito a 2TB (per ognuno dei quattro dischi IDE collegabili ad una macchina virtuale) esattamente come per i dischi SCSI. In Virtual Server 2005 si è sempre consigliato l’uso di dischi virtuali SCSI per avere migliori prestazioni. In Hyper-V i dischi virtuali IDE e SCSI, quando sono installati gli Integration Services, 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 Hyper-V supporta fino a 256 hard disk virtuali distribuiti su un quattro (numero massimo) controller SCSI virtuali. A differenza di Virtual Server 2005, non è possibile avviare le macchine virtuali da dischi virtuali connessi al bus SCSI virtuale 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.

Il supporto di rete in Hyper-V Ho lasciato per ultima la parte relativa al supporto di rete . Hyper-V introduce alcune importanti novità relative al networking rispetto a Virtual Server 2005 R2 SP1: SUPPORTO DI DODICI ADATTATORI DI RETE VIRTUALI PER OGNI MACCHINA VIRTUALE Le dodici schede totali sono suddivise in quattro Legacy Network Adapter e otto Network Adpater. Le prime quattro sono schede di rete virtuali emulate (full emulation) e mimano il comportamento di una scheda Ethernet Intel/DEC 21140. La presenza di queste schede consente di avere connessione di rete in macchine virtuali che non hanno installati gli Integration Services. Esempi di questa situazione possono essere sistemi operativi per cui gli IS non sono stati sviluppati o durante la fase di installazione di sistemi operativi per cui gli IS esistono, ma possono essere aggiunti solo dopo il termine dell’installazione. Queste schede sono molto più lente delle schede sintetiche. Le seconde otto sono schede sintetiche e sono disponibili installando nella macchina virtuale il Virtualization Service Client (VSC) per la rete che è parte degli Integration Services. Queste schede rappresentano la scelta obbligata se si richiedono performance di rete adeguate agli ambienti di produzione. SUPPORTO PER SWITCH VIRTUALI Virtual Server 2005 fornisce un supporto per reti virtuali che è equivalente ad un hub con una porta di uplink. Si deve tenere presente che con un hub è possibile da un computer sniffare i pacchetti di rete di un altro computer. Questo è vero sia per hub e macchine fisiche sia, ed è documentato nella Administration Guide, per Virtual Server. In Hyper-V è disponibile uno switch virtuale. La principale differenza è che uno switch (anche quello virtuale di Hyper-V) ha un algoritmo di apprendimento che consente di inviare i pacchetti solo alle corrette porte di

15


destinazione e non a tutte le porte come avviene con un hub. Lo switch virtuale è completamente configurabile via codice usando l’interfaccia WMI messa a disposizione da Hyper-V. SUPPORTO DI 802.1Q (VLAN TAGGING) In Hyper-V è disponibile il supporto allo standard 802.1q (VLAN Tagging) sia per le schede emulate che per i device di rete sintetici. Non sono invece supportati, nel primo rilascio, gli standard 802.1p (prioritized packets), 802.1x (port based network access control), TOE e le Jumbo frame. Tutte queste funzionalità sono nella lista delle priorità per una successiva release di Hyper-V. La mancanza di supporto a 802.1x rende impossibile usare questa tecnologia per mettere in quarantena una macchina virtuale con NAP (Network Access Protection) basato su 802.1x. Sarà comunque possibile mettere in quarantena una macchina virtuale in esecuzione in Hyper-V usando NAP con IPSec. Chi volesse avere maggiori informazioni (introduttive e di dettaglio) su NAP può partire da questo link: http://technet.microsoft.com/en-us/network/bb545879.aspx .

16

aaaaaaa  

aaaaaaaaaaaa

Read more
Read more
Similar to
Popular now
Just for you