Come trarre vantaggio dalla virtualizzazione annidata?
Probabilmente molti di voi si chiederanno che senso può avere creare più strati di virtualizzazione, la risposta è semplice: NON HA NESSUN SENSO…o quasi!.
Se osserviamo la cosa dal punto di vista “utilizzo delle risorse” non ha appunto nessun senso, se non quello di complicarsi la vita, ma se la osserviamo dal punto di vista “analisi e troubleshooting” probabilmente potrebbe averne.
Avere la responsabilità della gestione del server ESX comporta anche avere la responsabilità delle macchine virtuali ivi ospitate, occorre quindi prestare molta cura alla salute dell’host ESX.
Il rinnovo tecnologico, l’evoluzione della tecnologia della virtualizzazione stessa, generano inevitabilmente delle complicazioni che spesso si traducono nella necessità di installare upgrade oppure fix dell’hipervisor, che al loro volta introducono ulteriori complicazioni, infatti non sempre le procedure di fix o di upgrade di un sistema sono indolori.
Da tutto ciò, nasce la necessità di compiere analisi e verifiche in tal senso.
Ecco come installare un Virtual ESX (vESX):

Create una VM “custom”
Operative System: Linux Red Hat Enterprise 5 (64 bit)
Virtual Processors: 1 (o anche più, avendo cura di impostare l’affinity di ciascun Virtual Processor su altrettanti Phisical Processor)
Memory Size: 2048 MB
Network Adapter: 2 (E1000)
SCSI controller type: LSI Logic parallel
Disk Size: Quanto basta
Montate la iso di VMWare ESX 4 e procedete con l’installazione come fareste per qualsiasi altra VM.

Terminata l’installazione, per accedere al vESX, dovete apportare qualche modifica alla configurazione del “vero” hypervisor, in particolare è necessario impostare la scheda di rete al quale è “bindato” il virtal switch che ospita linterfaccia di rete oppure la VLAN del vESX in modalita “promisqua” (promiscuous mode) affinche possa ricevere tutto il traffico di rete e propagarlo a sua volta al virtual switch del vESX stesso.

Attraverso il client vSphere, potrete adesso accedere al vESX e configurarlo per eseguire tutte le prove desiderate.

Nel prossimo articolo spiegherò come creare Virtual Machines all’interno del vESX appena installato.

Ultimamente sto implementando un ambiente di laboratorio su Hyper-V presso un cliente e dopo alcuni giorni di lavoro vi segnalo un paio dritte che a me hanno fatto risparmiare un pò di tempo (… e mal di pancia!)

Innanzitutto, se avete a disposzione un client Vista SP1, potrebbe essere utile amministrare i vostri server fisci e virtuali da snap-in. E’ vero che è già disponibile System Center Virtual Machine Manager che fornisce funzionalità aggiuntive, ma è anche vero che quest’ultimo necessita di licenza a parte. Nonostante questo, l’utilizzo dei Remote Server Administration Tool (o il singolo snap-in di Hyper-V) si è dimostrato molto efficace nella situazione in cui l’ho implementato. Il gorsso vantaggio riscontrato è che è possibile distribuire il tool di gestione remota avendo però il controllo delle operazioni che gli utenti possono effettuare sulle macchine virtuali e sul server, delegando in modo “abbastanza tranquillo” la gestione degli Hyper-V server.

Tutto ciò è fattibile grazie alla possibilità di creare “ruoli” custom all’interno della gestione dei server virtuali ai quali è possibile associare gruppi o utenti Active Directory. Ne mio caso ho utilizzato un ruolo “administrator” per la gestione completa dell’ambiente virtuale (creazione macchine virtuali, modifiche al HW virtuale, connessione alla console, ecc..) che è stata attribuita al team dei sistemisti, e di un ruolo “developer” per la gestione essenziale della mcchine (accensione\spegnimento, snapshot, ecc…) messo a disposizione del team di sviluppo.

Per i dettagli della implementazione di tale soluzione può tornarvi utile il seguente link per due motivi: primo perchè è quello che ha aiutato me e secondo perchè non vorrei prendermi meriti che non mi spettano!!

Un’altra situazione che potrebbe darvi qualche grattacapo è quella della modifica delle caratteristiche dei dischi virtuali (tipo, dimensione, ecc…): in questo caso ricordatevi sempre di controllare se ci sono degli snapshot!! Se avete creato delle “fotografie” in momenti diversi della vita del vostro server virtuale (troppo sdolcinato??) e dovete modificare la dimensione dei dischi per una qualsiasi ragione, eliminate gli snapshot, spegnete la macchina virtuale e attendete che le operazioni di merging siano terminate(anche se durante la modifica del disco prima del merge nessun pop-up vi avviserà che l’operazione crea danni a non finire…)

L’altra dritta che potrebbe risolvervi un pò di problemi, è quello di utilizzare nelle macchine virtuali le schede di rete Legacy invece delle schede che utilizzano i driver contenuti nelle “additions” di Hyper-V. Sinceramente non so ancora dirvi con precisione il motivo reale per cui i driver Legacy funzionano meglio di quelli inclusi nel role di 2008 ma credo sia dovuto alla “giovane età” del prodotto (anche se per molti versi mi ricordano i problemi che si hanno con la gestione delle netwok connection di Vista…): in ogni caso se ho qualche news vi terrò aggiornati. Nel frattempo posso dirvi che i consigli forniti sono maturati dopo diversi giorni di test su configurazioni di ambienti virtuali Windows 2003\2008 con implementati Sql 2005 e Share Point, ciò non toglie che sono gradite segnalazioni\delucidazioni da parte vostra in merito!

VMware versione ESX e’ dotato di tecnologia “VMotion“, che permette di spostare una istanza virtuale (Virtual Machine) tra vari server ESX senza che questa ne risenta in termini di disponibilita’.
DRS (Distributed Resource Scheduler) usa le funzionalita VMotion per raggruppare in “pool” di memoria e CPU molteplici server ESX. Questo permette di muovere dinamicamente le istanze virtuali tra i server ESX che compongono il DRS cluster al fine di ottenere il bilanciamento delle risorse e l’azzeramento del tempo di fermo. Raccoglie costantemente informazioni sull’utilizzo di risorse da parte dei server per generare “suggerimenti” e agevolare l’ottimizzazione del sistema virtuale. Il livello di automazione col quale avviene la gestione degli spostamenti dipende da criteri precedentemente definiti e possono essere manuali o totalmente automatizzati.

Come alcuni di voi sapranno, per i sistemi operativi è importantissimo il realtime .
Purtroppo per un sistema “guest” (virtuale), non avendo un “contatto” diretto con l’hardware, il tempo tende a scorrere troppo velocemente o troppo lentamente rispetto alla realtà.
Fatto accaduto ad un paio di guest con OS Linux (CentOS 4.3 su VMWare GSX), installate nel datacenter di un mio cliente.
Nonostante tentassi di mantenere sincronizzare l’orologio con l’NTP, a distanza di qualche ora cominciavano ad accusare rallentamenti.
Dopo un po’ di ricerche e tentativi, ho adottato la soluzione di avviare il sistema operativo con il parametro noapic nolapic, installare i tools, inserire il parametro tools.syncTime = “TRUE” nel file di configurazione della macchina virtuale (*.vmx) e l’NTP ha fatto il resto.