venerdì 10 aprile 2015

vGPU in vSphere 6.0/Horizon 6.1 con NVIDIA GRID K1 K2

Recentemente ho implementato un ambiente vsphere 6.0 + Horizon View 6.1 con delle NVIDIA GRID GPU. Con questa feature, diamo la possibilità a diverse VM di utilizzare una scheda grafica NVIDIA (K1 o K2) installata su di un host,  sfruttando il driver NVIDIA  sviluppato per macchine fisiche, i guests utilizzeranno queste vGPU condivise nello stesso modo in cui utilizzerebbero una GPU riservata (Pass-through) ottenendo un completo supporto applicativo.

Le 2 schede grafice supportate sono:
GRID K1: 4 GPU con 4GB DDR3 e 192 CUDA cores per ogni GPU (equivalente ad una Kepler k600 GPU)
GRID K2: 2 GPU con 4GB DDR5  e 1536 CUDA cores per ogni GPU (equivalente ad una  Kepler k5000 GPU)


Ogni  guest che utilizza una vGPU verrà acceso in un host del cluster che abbia a bordo una scheda grafica con delle GPU disponibili per quel guest. All'interno di un singolo host, i guests vengono distribuiti su tutte le GPU fisiche disponibili.
La condivisione avviene attraverso l'assegnazione di profili, ogni profilo assegna una quantità di RAM ed un numero di diaply massimo per ogni VM, ecco l'elenco dei profili attualmente disponibili:



INSTALLAZIONE:

1) installazione del NVIDIA GRID vGPU Manager in ogni server ESXi del cluster:
Il download del VIB viene fatto dalla pagina dei download di NVIDIA, selezionando:

per installare i VIB, dopo aver messo l'host in maintenance mode, ci si connette in SSH e si lancia il comando:
esxcli software vib install --no-sig-check -v /<path>/ NVIDIA-vgx-VMware-346.27-1OEM.600.0.0.2159203.x86_64.VIB
Al termine dell'installazione, anche se non esplicitamente richiesto, dobbiamo operare un reboot dell'host.

2) in vcenter creare un cluster che ospiterà con tutti i server con una scheda GRID

3)  nel cluster creare un nuova windows VM a cui aggiungiamo uno SHARED PCI DEVICE di tipo NVIDIA GRID VGPU ed assegnamo il profilo desiderato:



4) Al power on della VM, verrà assegnata una vGPU utilizzando in toto o in parte una GPU fisica. Ora è il momento di installare i drivers all'interno del guest. Faacendo sempre riferimento all'area download del sito invidia, scarichiamo e successivamente installiamo i drivers corretti per il guest OS


5) Volendo utilizzarla come master image di un pool view (sia linked che full clone) basterà spegnerla, ricavarne una snapshot od un template e nella creazione del pool impostare:
Default Display Porotocol = PCOIP
Allow User to choose Protocol = NO
3D Render = NVIDIA GRID VGPU


Chiaramente queste VM sono legate al device PCI (GPU) e quindi non supportano il vMotion ma possono essere spostate a freddo su un host che contine GPU dello stesso tipo.

Qui sotto potete vedere un filmato relativo ad una VM che sta ultilizzando una vGPU con profilo k260q, la console della VM è raggiungibile con protocollo PCOIP da un thin client Praim A9050

video




vSwitch e DVS: number of ports

In vista dell'esame VCP6-DCV, di cui è da poco uscita la versione beta, un corsista mi chiede:
"un vswitch è, come in passato, composto da 120 porte ? Serve ancora il reboot per modificarne il numero ? Lo stesso vale per un distribuito? Dove lo vedo nella web gui?"

Fcciamo chiarezza:

Usando il vSphere Client tradizionale, dalle proprietà di un vSwitch standard vedo che è composto da 120 porte, ne posso modificare il numero fino ad un massimo di 4088 e, per questa operazione è necessario un reboot. In realtà questa informazione non è corretta: dalla versione 5.5 il numero di porte di un  vSwitch standard è impostato con Elastic il numero minimo di porte viene incrementato/decrementato  di 8 in 8 secondo necessità (KB2064511).

Sempre utilizzando il client tradizionale, vedo che il numero di porte di un DVS è dato dalla somma delle porte di ogni portgroup, per default un pgroup viene creato con 8 porte, ed è un valore modificabile senza la necessità di un reboot. Dalla GUI si evince che il binding è di tipo static (la porta viene assegnata e riservata da un VM nel momento in cui viene connessa allo switch), e può essere modificato in dynamic (la porta viene assegnata alla VM solo nel momento in cui la VM è accesa e la scheda di rete è connessa allo switch, è una modalità deprecata fin dalla 5.0) o ephemeral (la porta viene creata ed asegnata solo nel momento in cui la VM è accesa e la scheda di rete è connessa allo switch, se la macchina viene spenta o disconnessa, la porta viene cancellata).

Utilizando il web client, per quanto riguarda il DVS, le info non si discostano molto rispetto alle info del client tradizionale: il numero di porte di un DVS è dato dalla somma delle porte di ogni portgroup. esistono i 3 tipi di binding e per il binding di tipo static esiste un'ulteriore opzione chiamata Port Allcocation: selezionando elastic, il numero di porte specificato costituisce il numero minimo di porte che poi verrà incrementato  di 8 in 8 secondo necessità mentre selezionando fixed il numero di porte specificato costituisce il numero massimo di porte che non verrà incrementato.

martedì 17 febbraio 2015

VPX operational dashboard

Nel vSphere web client, cliccando HOME > LOG BROWSER abbiamo uno strumento che ci permette di visualizzare i logs di VCenter e degli host ESXi.


Esiste anche un altro tool per visualizzare atri log esistenti a livello di VCenter: il VPX Operational Dashboard (VOD). Per accedere a questo tool, puntiamo a https://<VC_hostname>/vod/index.html.

Tra le varie informzioni disponibili, cliccando HOST STATUS possiamo visulaizzare il MOID di ogni host

lunedì 12 gennaio 2015

vSphere Virtual Flash Resource

Due sono le features presenti in vSphere 5.5 che utilizzano su dispositivi di memoria FLASH o  SSD:
Virtual Flash Host Swap Cache for VMware vSphere Hypervisor
Virtual Flash Read Cache for virtual machines

Il cosidetto vSphere Flash Read Cache framework è basto su due componenti:
 vSphere Flash Read Cache infrastructure
 vSphere Flash Read Cache software
Attraverso esse, potremo raggruppare (pooling) diversi devices  Flash (installati localmente su ogni host) in un singolo oggetto chiamatoVirtual Flash Resource.
Per crearla su ogni host:


La fetaure Virtual Flash Host Swap Cache for VMware vSphere Hypervisor, permette agli host di utilizzare parte della Virtual Flash Resource per una cache utilizzate dalle VM in stato di VMKernel swapping, il massimo di risorse consumabili a questo scopo è 4 TB e la quantità di risorsa selezionata viene 'riservata' per questa feature: NON può essere utilizzata per la Flash Read Cache.
Per abilitarla su ogni host:



La feature Virtual Flash Read Cache for virtual machines è una cache in lettura (write-through) utilizzata dalle VM le cui performances aumentano notevolmente senza impatti sulla possibilità di utilizzare fetaures quali vMotion, HA, DRS.
Questa cache può essere abilitata per singolo VMDK (via web client con HW version 10), viene considerata come una RESERVATION con le relative regole di admission control.
Per abilitarla sui VMDK:
Premendo il tast advanced possiamo anche scegliere il blocksize in base alle richieste dei guest OS / applicazioni (con il tool vscsistats possiamo scoprire il blocksize utilizzato dalle VM).








martedì 4 novembre 2014

horizon mirage bandwidth limit

Dalla versione 5.1 di Horizon Mirage, è stata introdotta la possibilità di impostare un limite di banda in upload/download per i client che si trovano in alcune subnet o in alcuni domini.
Chiaramente è una funzionalità molto utile per far si che i clients che si trovano in uffici remoti non consumino tutta la banda con le attività mirage.
Per impostare il limite, nella mirage console, clicchiamo col tasto destro su system configuration e selezioniamo SETTINGS. Ora ci spostiamo sul tab BANDWITH LIMITING


Come vedete, per default non c'è nessun limite impostato. Ora, per impostare i limiti desiderati, creiamo un file csv contenente le regole nel formato:   SubnetMaskV4,Site,Download limit,Upload limit.



Nell'esempio, impostiamo un limite di 500KB/s in upload e di 350KB/s in download per tutti i clients della subnet 172.16.0.0/16.
Impostiamo un limite di 300KB/s in entrambe le direzioni per il client 172.16.0.11
Impostiamo un limite di 200 e 100 KB/s per i cliient del dominio sitoA ed un limite di 2048 1024 per i client del dominio sitoB. Importando il file otteniamo:



La regola di precedenza è la più restrittiva. Se ,ad esempio, un client appartiene al sitoA, alla subnet 172.16.0.0  ed il suo indirizzo è 172.16.0.111, i suoi limiti saranno 200 KB/s in upload e 100 KB/s in download. Vince questa regola, NON perchè è stata inserita per ultima ma perchè è la più restrittiva. 

Impostare la banda in upload e in download per una intera subnet (o dominio) , significa che se all'interno della subnet ci sono attività parallele di download ed upload, la banda massima utilizzabile sarà la sommo dei due limiti.




venerdì 26 settembre 2014

vSphere storage polcies nel web client

L'utilizzo delle sorage policies e degli storage profiles con il vSphere web client è meno articolato rispetto all'utilizzo delle stesse features nel client tradizionale.

Come in passato, se abbiamo dello storage che attraverso le API VASA, è in grado di comunicare al vCenter le caratteristiche delle LUN, avremo già nel sistema alcune storage capabilities e quando da HOME > VM STORAGE POLICIES andremo a creare una nuova policy, ci verranno elencate le STORAGE CAPABILITIES esistenti con cui potremo creare un set di regole che descriveranno la nostra policies (installando la VSAN vengono create 5 capabilities).
.
Se invece vogliamo lavorare con le USER DEFINED STORAGE CAPABILITIES, nel web client dobbiamo affidarci ai TAG: ogni datastore potrà essere descritto con diversi TAG (dall'inventario datastores/manage/tags) e quando andremo a creare una nuova storage policy potremo utilizzare i TAG assegnati ai DATASTORES per creare il set di regole desiserato.
Per visualizzare tutti i TAG creati, è possibile cliccare TAGS dalla web client HOME.


Ogni TAG deve appartenere ad una CATEGORY ed ogni categoria verrà associata ad uno o più tipi di oggetti (entità) del nostro vcenter (datastore, host, vm, network ecc.)



giovedì 25 settembre 2014

PernixData FVP nel Partner Verified and Supported Products (PVSP) di VMware

In un post precedente, si diceva che il software PernixData FVP viene installato a livello di hypervisor, quindi si tratta di un estensione, di un modulo che estende le funzionalità del vmkernel.
Alcuni clienti mi hanno chiesto se un modulo di terze parti installato a livello di vmkernel, potrebbe provocare 'problemi' di supporto da parte di VMware ad eventuali problemi aperti. La risposta è che da marzo 2014 FVP è stato aggiunto al VMware Partner Verified and Supported Product Program, ed è quindi riconosciuto da VMware come prodotto ufficialmente pronto per essere installato nella piattaforma vSphere. Maggiori informazione le potete trovare in una press release di PernixData, nell'elenco dei Partner Verified and Supported Products (PVSP) sul sito VMware e nella VMware  KB 2073257.