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.

Ebbene si’, anche io, mio malgrado, sono passato a Windows 7.
Purtroppo era diventato impossibile lavorare con Windows Vista e Windows XP a 64 bit non e’ il massimo.
Appena terminata l’installazione ho cominciato a “destreggiarmi” tra i vari menu, installando per primi i programmi “utili” e proprio terminata l’installazione di “VMware vSphere Client”, provando ad accedere al Virtual Center, mi e’ comparso il seguente errore:

e successivamente:

Ovviamente, conscio che qualcosa non avrebbe funzionato con la nuova versione di Windows, mi sono messo alla ricerca di una possibile soluzione.
Il sito VMware propone l’aggiornamento a vSphere 4 Update 1 per supportare Windows 7 e Windows 2008 R2, ma in attesa di procedere con l’aggiornamento, prendendo vari spunti qua’ e la’ ecco il “Workaround”.

Fase 1

• Procuratevi il file “System.dll” da un sistema operativo diverso da Windows 7 sul quale e’ installato il framework 3.5 (il file lo trovate in %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\), considerando, qualora utilizziate un sistema a 64 bit, di prelevare la versione del file a 32 bit (il client vSphere e’ comunque a 32 bit)

Fase 2

• Copiate il file in una directory creata ad hoc (es. lib) in %ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher

Fase 3

• Editate il file VpxClient.exe.config inserendo il blocco

  <runtime>
  <developmentMode developerInstallation="true"/>
  </runtime>

  appena prima del tag “</configuration>”

Fase 4

• Lanciate SystemPropertiesAdvanced.exe, premete il pulsante ‘Variabili d’ambiente‘ e create la variabile di sistema “DEVPATH” con riferimento alla directory contenente il file “System.dll” (Fase 2).

Dopo aver riavviato l’istanza di Explorer.exe oppure il computer, per rendere la variabile visibile al sistema, dovreste poter accedere al Virtual Center.

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.