Cerca nel blog

venerdì 30 aprile 2010

VM Memory Overhead con vSphere 4.0 Update 1

Per amministrare un ambiente virtuale è necessario comprendere l’utilizzo delle risorse, ed in particolar modo la memoria RAM, che risulta essere la risorsa che viene consumata per prima.

Oltre alla memoria consumata per il VMkernel, la Service Console (solo per ESX) e la memoria assegnata al guest OS bisogna tenere conto dell’overhead della VM, ovvero la quantità di memoria necessaria all’hypervisor per gestire la VM. Questo overhead è direttamente proporzionale alle dimensioni della VM.

Per le versioni precedenti a vSphere è possibile consultare i seguenti articoli inerenti all’argomento:
Riprendendo le categorie proposte dagli articoli precedenti osserviamo le differenze di overhead, indicando tra le parentesi il valore della versione 3.5 di ESX:
  • VM Entry composta da: 1 vCPU, 1 GB di memoria RAM comporta un overhead di MB 123,73 MB (97,35 MB);
  • VM Media composta da: 2 vCPU, 4 GB di memoria RAM bit comporta un overhead di 242,51 MB (195,27 MB);
  • VM Grande composta da: 4 vCPU, 16 GB di memoria RAM comporta un overhead di 591,76 MB (573,85)
  • VM Very Big (ESX 3.5) composta da: 4 vCPU, 64 GB di memoria RAM bit comporta un overhead di 1.660,09 MB (1.875,48 MB);
  • VM Very Big (vSphere) composta da: 8 vCPU, 256 GB di memoria RAM comporta un overhead di 10.328,69 MB;
Da notare che per vSphere non esiste più una differenza relativa tra sistemi operativi a 32 bit e sistemi a 64 bit.

Per maggiori informazioni consulatare la “Resource Management Guide”, su vSphere cercando il capitolo “Overhead Memory on Virtual Machines” oppure puntare alla “VMware vSphere Online Library ESX 4.0 Update 1 and vCenter Server 4.0 Update 1 Edition”.

mercoledì 28 aprile 2010

Disponibile la VMware Support Toolbar

Da qualche giorno è disponibile un nuovo strumento per consultare più semplicemente i contenuti del sito VMware, si tratta della VMware Support Toolbar.

Si tratta di un plug-in per il proprio browser, strumento tanto semplice quanto utile, che permette di accedere rapidamente alle patch, alla documentazione ed alla Knowledge Base di VMware.

Grazie alla toolbar è possibile tenersi aggiornati sugli sviluppi del supporto tecnico VMware grazie a RSS e Twitter, oltre a poter chattare “uno a uno” con lo staff VMware o altri esperti della community (feature ancora da attivare).

E’ possibile, inoltre, effettuare ricerche full text sfruttando il motore di google, con la possibilità di circoscrivere l’area di ricerca all’intero WEB, al sito VMware o alla Knowledge Base.

La VMware toolbar funziona con on IE, Firefox, Safari ed è stata sviluppata facendo leva sulla tecnologia offerta da counduit.

Per maggiori informazioni consultare il sito VMware Support Toolbar

martedì 27 aprile 2010

Supporto per l’installazione di ESXi su dispositivi USB/SD

ESXi è disponibile in 2 versioni, Embedded e Installable. Uno dei principali vantaggi della versione Embedded consiste nel non dover installare il software, che si trova alloggiato ad una periferica interna (USB/SD/Disk module) fornita dal vendor.

E’ possibile trovarsi in condizioni di avere un server fisico in HCL per ESXi e, non avendo optato per ESXi Embedded al momento dell’acquisto, la scelta di installare ESX o ESXi spesso pende per la versione “tradizionale di ESX”. Tale scelta è spesso avvalorata da anni di utilizzo di ESX e della shell fornita dalla Service Console. Questa scelta, comunqe, si andrà rivista in funzione delle evoluzioni in casa VMware che sta già percorrendo la strada per “abbandonare” ESX in favore di ESXi in quanto più sicura e con un minore overhead.

Un ulteriore incentivo verso ESXi può essere il supporto per l’installazione di ESXì su periferiche USB/SD. Infatti, con il rilascio di vSphere 4.0, VMware ha reso possibile l’installazione del software su periferiche USB o SD flash direttamente connesse al server. Il supporto è subordinato a due condizioni:
  • il server fisico deve essere presente nella Hardware Compatibility Guide per ESXi;
  • il device (USB/SD) deve essere approvato dall'HW vendor per quella tipologia specifica di server.
Per quanto riguarda l’installazione gli step sono identici all’installazione su disco fisso, con l’eccezione della scelta della flash card nella fase di selezione del disco di installazione per l'hypervisor.

Per maggiori informazioni consultare la KB 1010574.
Supporto per l’installazione di ESXi su dispositivi USB/SD

giovedì 22 aprile 2010

Il comando esxcli

Il comando esxcli permette di gestire dalla CLI la componente di storage di ESX nota come PSA (Pluggable Storage Architecture). Elementi come i path verso lo storage, plugin per il mutipathing e LUN masking possono essere gestiti anche via script.

La sintassi del comando non è intuitiva e la composizione del comando richiede parecchi argomenti.
Il primo argomento richiesto è il namespace che permette all’utente di specificare in quale ambito si desidera utilizzare il comando scegliendo tra:
  • corestorage: spazio relativo ai comandi sullo storage e le regole che si desidera utilizzare.
  • nmp: spazio relative al VMware Native Multipath Plugin (NMP) ovvero il plugin VMware di default nell’implementazione della PSA
  • swiscsi: riservato alla gestione dei comandi iSCSI
Qualche esempio:
  • il comando “esxcli corestorage claimrule list” restituisce l’elenco delle regole applicate allo storage in uso;
  • il comando “esxcli nmp satp list” restituisce i plugin SATP (Storage Array Type Plugin) supportati di default da ESX;
output del comando esxcli

Oltre ad ottenere delle liste è possibile eseguire delle azioni, ad esempio in passato per mascherare una LUN dall’host ESX si ricorreva al parametro avanzato Disk.MaskLUNs, mentre con la vSphere lo stesso risultato è ottenibile aggiungendo delle apposite regole.

In primo luogo si chiede la lista delle regole esistenti:
  • esxcli corestorage claimrule list
Ora si aggiunge una regola on la sintassi esxcli corestorage claimrule add -r "numero della regola" -P "Multipathing Plugins" -t "tipo" -A "adattatore" -C "canale" -T "target" -L "LUNid”. E' necessario aggiungere una regola per ogni percorso da mascherare:
  • esxcli corestorage claimrule add -r 102 -P MASK_PATH -t location -A vmhba1 -C 0 -T 0 -L 0
  • esxcli corestorage claimrule add -r 103 -P MASK_PATH -t location -A vmhba2 -C 0 -T 1 -L 0
Vengono caricate le regole:
  • esxcli corestorage claimrule load
Viene richiesto di “rigettare” il path per una specifico tipo ed adattatore:
  • esxcli corestorage claiming unclaim -t location -A vmhba1
  • esxcli corestorage claiming unclaim -t location -A vmhba2
Vengono eseguite le regole
  • esxcli corestorage claimrule run
Risultato dell'applicazione della regola di Masking vista nel vSphere Client

Per maggiori infomazioni consultare la guida "Fibre Channel SAN Configuration Guide" alla voce "Managing Storage Paths and Multipathing Plug-Ins"



lunedì 19 aprile 2010

Guida per la messa in sicurezza di vSphere 4

Da qualche ora VMware ha rilasciato la guida per mettere in sicurezza ESX 4. La guida è stata realizzata grazie ai feedback ed all’osservazione della community relativa alla bozza della guida rilasciata in gennaio.

Tra le novità, rispetto alla guida della versione precedente, spicca il nuovo approccio al documento come:
  • struttura del documento, per migliorare la chiarezza dei punti affrontati;
  • livello di raccomandazione, applicato ad ogni linea guida per permettere agli amministratori di scegliere le guidelines che meglio si applicano al proprio ambiente.
La guida è strutturata in più di 100 linee guida suddivise nelle seguenti sezioni:
  • Introduzione
  • Virtual Machine
  • Host (ESXi e ESX)
  • vNetwork
  • vCenter
  • Console OS (solo per ESX)
La parte introduttiva si preoccupa di definire: gli obiettivi del documento, la suddivisione degli argomenti, i livelli di raccomandazione e tutti gli aspetti strutturali della guida.

Per maggiori informazioni consultare:

venerdì 16 aprile 2010

Service Console: questione di memoria

L’installazione di ESX Server porta con sé la Service Console (COS) componente basata su sistema operativo linux per l’amministrazione dell’host che fornisce anche gli strumenti per la gestione via CLI del vmkernel. La quantità di memoria RAM assegnata nella fase di installazione non rappresenta la quantità massima gestibile dal sistema. Il tetto massimo di memoria assegnabile alla COS, fin dalla versione 2.x, è pari a 800 MB.

In condizioni normali i valori di default sono sufficienti per la gestione delle VM e dei servizi offerti dalla Service Console (come SSH e Apache), tuttavia ci possono essere delle condizioni nelle quali VMware raccomanda di incrementare la quantità di RAM,condizioni quali:
  • utilizzo di software di management di terze parti nella console;
  • presenza di agenti di backup;
  • quando si osserva un massiccio utilizzo di swap nella console;
  • quando ESX partecipa ad un cluster VMware High Availability (HA) (si rimanda alla KB 1012002 relativa a ESX 3.5).
Nel corso dei rilasci di ESX la quantità di memoria assegnata di default alla Service Console è cambiata con questa con questa evoluzione:
  • ESX 2.x: memoria di default 192 MB,in questa versione la necessità di aumentare memoria è in funzione del numero di VM gestite da ESX (esempio 192 MB per 8 VM);
  • ESX 3.x: memoria di default 272;
  • ESX4.x: la memoria di default è in funzione della quantità di RAM fisica installata nel server.
In particolar modo per ESX4 la memoria di default segue questo schema:
  • Host con 8 GB: 300 MB
  • Host con 16 GB: 400 MB
  • Host con 32 GB: 500 MB
  • Host con 64 GB: 602 MB
  • Host con 128 GB: 703 MB
La modifica della memoria della COS avviene dal vSphere client puntando all’host ESX quindi alla scheda Configuration/Memory e, una volta chieste le proprietà, nella dialog si inserirà il nuovo valore. La modifica della memoria RAM della COS richiede il riavvio del server.

Procedura per la modifica della memoria RAM per la Service Console

Per maggiori informazioni consultare la KB 1003501.

mercoledì 14 aprile 2010

Backup di VM e Change Block Tracking (CBT)

A partire da ESX 4.0 e successive, le Macchine Virtuali con virtual hardware 7, possono tener traccia dei settori dei dischi che sono cambiati, questa features è chiamata Changed Block Tracking (CBT).

Più precisamente è nel layer di virtualizzazione che viene tenuta traccia del cambiamento del blocco del disco. Grazie a questo principio, dopo il primo backup, quelli successivi si preoccupano di salvare solo i blocchi modificati rispetto all’ultimo salvataggio.

Di default la features è disabilitata in quanto può incidere sulle performance della VM, tuttavia utilizzando i software che fanno leva su questa tecnologia, come VMware Data Recovery, questa viene attivata.

Per verificare se la funzionalità è abilitata è possibile utilizzare:
  • un editor per file di testo ed agire sul file vmx della VM che si desidera analizzare;
  • il vSphere Client, per editare i parameti della VM, puntando alla scheda Options, quindi Advanced, General e permere il bottone “Configuration Parameters”

Parametri della VM (VMX) visti dal vSphere Client

In entrambe i casi è necessario e cercare il valore ctkEnabled. Se questo equivale a TRUE allora la features è abilitata. Non solo, per ogni disco virtuale sarà presente una stringa con la sintassi scsix:x:.ctkEnabled = "TRUE" (dove x:x è il disco virtuale).

Listando inoltre il contenuto del datastore da riga di comando, alla ricerca dei file VMDK, oltre ai comuni file descrittori, flat, delta si troverà il file *-ctk.vmdk. All’interno di questo file ogni blocco del disco virtuale è salvato secondo una sequenza numerica che permette alle applicazioni per il backup di comprendere se un blocco è stato modificato oppure no. Le dimensioni di questo file dipendono dal disco virtuale e rimangono fisse fin tanto che il disco virtuale rimane delle stesse dimensioni.

Changed Block Tracking non è utilizzabile in condizioni di:
  • il virtual hardware non in versione 7;
  • il disco virtuale in formato RDM in modalità fisica
  • il disco virtuale connesso ad un controller SCSI (virtuale) in modalità “shared”
Changed Block Tracking è utilizzabile con:
  • tutti i dischi virtuali thin o thick
  • tutti i datastore SAN iSCSI/FC e NAS
Per maggiori informazioni consultare la KB 1020128

Backup di VM e Change Block Tracking (CBT)



A partire da ESX 4.0 e successive le Macchine Virtuali con virtual hardware 7, possono tener traccia dei settori dei dischi che sono cambiati, questa features è chiamata Changed Block Tracking (CBT).


Più precisamente è nel layer di virtualizzazione che viene tenuta traccia del cambiamento del blocco del disco. Grazie a questo principio, dopo il primo backup, quelli successivi si preoccupano di salvare solo i blocchi modificati rispetto all’ultimo salvataggio.


Di default la features è disabilitata in quanto può incidere sulle performance della VM, tuttavia utilizzando i software che fanno leva su questa tecnologia, come VMware Data Recovery, questa viene attivata.



Per verificare se la funzionalità è abilitata è possibile utilizzare:


un editor per file di testo ed agire sul file vmx della VM che si desidera analizzare;


il vSphere Client, per editare i parameti della VM, puntando alla scheda Options, quindi Advanced, General e permere il bottone “Configuration Parameters”



In entrambe i casi è necessario e cercare il valore ctkEnabled.Se questo equivale a TRUE allora la features è abilitata. Non solo, per ogni disco virtuale sarà presente una stringa con la sintassi scsix:x:.ctkEnabled = "TRUE" (dove x:x è il disco virtuale).


Listando inoltre il contenuto del datastore da riga di comando, alla ricerca dei file VMDK, oltre ai comuni file descrittori, flat, delta si troverà il file *-ctk.vmdk


All’interno di questo file ogni blocco del disco virtuale è salvato secondo una sequenza numerica che permette alle applicazioni per il backup di comprendere se un blocco è stato modificato oppure no. Le dimensioni di questo file dipendono dal disco virtuale e rimangono fisse fin tanto che il disco virtuale rimane delle stesse dimensioni.


Changed Block Tracking non è utilizzabile in condizioni di:


il virtual hardware non in versione 7;


il disco virtuale in formato RDM in modalità fisica


il disco virtuale connesso ad un controller SCSI (virtuale) in modalità “shared”


Changed Block Tracking è utilizzabile con


tutti i dischi virtuali thin o thick


tutti i datastore SAN iSCSI/FC eNAS



Per maggiori informazioni consultare la KB 1020128



lunedì 12 aprile 2010

Lo schedulatore di ESX 4.x e hyper-threading

Lo schedulatore di ESX 4.x permette di disciplinare l’accesso alle risorse fisiche da parte delle VM, soprattutto in presenza di regole quali riserve, limiti e shares. Utilizzando processori con hyper-threading, tecnologia che sta vivendo una nuova primavera, è possibile che una schedulazione più frequente non corrisponda ad avere la garanzia di una maggiore performance, questo perché la quantità di risorse ricevute dalle VM è influenzata dalla CPU logica appartenente allo stesso core fisico.

In questi casi è possibile lavorare sul parametro HaltingIdleMsecPenalty che determina l’algoritmo utilizzato per il bilanciamento del carico dei core fisici in base all’aggressività delle CPU virtuali. Il parametro HaltingIdleMsecPenalty è un parametro avanzato dell’host ESX, quindi in presenza di cluster o più HOST è necessario adeguare tutti server allo stesso comportamento.

Per agire sul parametro su ESX, dalla console digitare il comando:

  • esxcfg-advcfg --set <valore desiderato> /Cpu/HaltingIdleMsecPenalty
Impostazione del parametro HaltingIdleMsecPenalty

Per agire sul parametro su ESXi, dalla vMA (ottenuto l’accesso all’host), lanciare il comando:
  • vicfg-advcfg --set <valore desiderato> /Cpu/HaltingIdleMsecPenalty
Il valore desiderato va da 0 a 10.000, nell’ultima release di ESX 4

Da notare che impostare il parametro ad un valore troppo elevato potrebbe diminuire l’accuratezza dei settaggi delle risorse, soprattutto relative alle riserve ed alle shares delle VM. Inoltre nella stragrande maggior parte delle circostanze impostare il parametro ad un valore superiore al default non ha impatti sulle performance.

Per maggiori informazioni consultare le KB 1020233

giovedì 1 aprile 2010

Hot Add, Hot Plug… a kind of magic

Spesso nella comparazione delle versioni disponibili di vSphere si pensa alle features più blasonate (VMware Fault Tollerance, VMotion, DRS, ecc.) tralasciando quelle “minori”, soprattutto se nella versione precedente queste erano disponibili.

Parlando della fetures “Hot Add” ci si è sempre riferiti alla capacità di aggiungere, ed in alcuni casi di togliere, dinamicamente in una macchina virtuale accesa CPU e RAM, a patto che il guest OS sia in grado di supportare tali modifiche.

E per quanto riguarda l’aggiunta a VM accesa di dischi virtuali? Questa features prende il nome di “Hot Plug” e la risposta appare scontata, soprattutto se si ha dimestichezza con la Virtual Infrastructure 3 la quale supporta questa funzionalità anche nelle versioni non enterprise. Ma la sorpresa è dietro l’angolo …

Aggiunta disco virtuale su ESX con licenza Essential e Standard

Dalle immagini si evince che per le versioni Essential e Standard la licenza non copre l’aggiunta a caldo del disco per la quale è necessaria almeno la versione Advanced. Sotto il profilo delle licenze, quindi “Hot Add” e “Hot Plug” fanno parte della stessa categoria.

Ad oggi le cose non stanno proprio così, anche se non è dato a sapere se si è trattato di un BUG del software o meno, ma con la versione 4.0 Update 1 la funzionalità “hot plug” è tornata disponibile. Il problema è trovare un documento che ne “certifichi” il ritorno.

Aggiunta disco virtuale su VM ospitata su ESX 4.0 U1

Qualche approfondimento: