VMware View 5.1: fornire la miglior End-User Experience

Posted on 3 maggio 2012 by Samuele

VMware View 5.1 mira ad una ulteriore ottimizzazione dell’esperienza utente attraverso un minor utilizzo di banda e l’allargamento dei device utilizzabili.

USB Enhancements: VMware ha riprogettato la funzionalità di USB redirect per i client Windows. Questa nuova feature non richiede più che il device driver venga installato lato client fisico, al suo posto viene implementato un generico “USB arbitrator”, mentre l’agente provvede ad implementare un “USB hub”. Con questo meccanismo VMware può ampliare il range di device USB supportati aumentando la granularità delle policy sui device (ad esempio abilitare/disabilitare la copia su dispositivi di massa) anche si periferiche USB multifunzione.

Supporto RADIUS: estesa la sicurezza lato autenticazione per View 5.1 Connection Server. Questa novità fornisce la possibilità di una scelta più ampia nell’implementazione del “single sign-on” o dei “security token” nei virtual deskotp.

PCoIP Enhancements: sono continui gli sforzi di VMware nell’incrementare i vantaggi offerti dal protocollo PCoIP. Queste migliorie non possono avvenire solo a livello di codice, quindi VMware ha pubblicato un White Paper che contiene le comparazioni ed i risultati dei test per i protocolli di remotizzazione considerati lo stato dell’arte per gli ambienti VDI.

Per maggiori informazioni è possibile:

Posted in View, VMware | Tagged | 1 Comment

VMware View 5.1: semplificazione della gestione e distribuzione dei desktop

Posted on 3 maggio 2012 by Samuele

Per questa area ci sono diverse migliorie:

View Persona Management: estensione delle funzionalità del prodotto ai desktop fisici con lo scopo di favorire per la migrazione da desktop fisici a virtuali. Questa nuova funzionalità dà la possibilità di migrare da Windows XP a Windows 7. L’agente di View Persona Management può essere installato sui desktop fisici senza dover installare VMware View agent , nel rispetto delle licenze acquistate. Durante una migrazione fisico-virtuale, un amministratore potrà installare View Persona Management sui desktop fisici, quanto l’utente passerà al desktop virtuale (con abilitato il Persona Management) vedrà automaticamente sincronizzati i suoi dati e tutti gli eventuali ulteriori parametri personali

VMware vCenter Operations for View: ulteriore novità, prodotto nato dall’integrazione con i prodotti di management di VMware (vCOps) dedicati ed ottimizzati per gli ambienti VDI. VMware vCenter Operations Manager for View fornisce un monitoraggio end-to-end dei desktop e degli utenti attraverso delle dashboard di facile comprensione per aiutare ad identificare, prevedere e risolvere potenziali problemi.

View Administrator Enhancements: funzionalità create per venire incontro alle necessità di alcuni clienti che utilizzano VMware View in ambienti particolarmente protetti nei quali le scritture su AD sono proibite. Con questa nuova versione di View l’amministratore può impostare una opzione nei parametri di configurazione per riutilizzare un account computer già esistente in AD durante il processo di provisioning.

VMware View Composer server in View 5.1: i miglioramenti sono stati apportati al prodotto per permettere una migliore scalabilità. Ora il prodotto può essere installato in un server stand-alone. L’amministratore potrà inoltre configurare il VMware View Connection Server, attraverso il comando vdmadmin, per inviare gli eventi ad un syslog al posto di usare un database. Non per ultimo i tempi di risposta dell’interfaccia utente sono stati migliorati proprio pensando agli ambienti di grandi dimensioni.

View Administrator Language Support: estesa la localizzazione del View Administrator per i paesi non anglofoni, questa estensione non riguarda la lingua Italiana (supporto per Francese, Tedesco, Giapponese, Coreano e Cinese)

Per maggiori informazioni è possibile:

Posted in View, VMware | Tagged | 1 Comment

VMware View 5.1: Abbassamento del TCO, attraverso l’ottimizzazione dello storage

Posted on 3 maggio 2012 by Samuele

Una novità di View 5.1 è View Storage Accelerator, una tecnologia che riduce il carico di lavoro generato sullo storage sfruttando la memoria dell’host locale quale cache delle richieste di lettura di più desktop, comportamento tipico degli ambienti VDI.

Questa tecnologia sfrutta una funzionalità offerta da vSphere a partire dalla versione 5 e successive, in quanto installata direttamente in ESXi, chiamata Content Based Read Cache (CBRC).

Quando questa funzione viene abilitata per specifiche VM, l’hypervisor scansiona i blocchi dello storage per generare un “indice” del contenuto di tali blocchi. Quando i blocchi sono letti dall’hypervisor vengono collocati nella cache CBCR e tutte le successive letture dei blocchi con lo stesso contenuto verranno servite direttamente dalla memoria.

Questa tecnologia migliora significativamente le performance dei desktop, soprattutto nelle fasi di accensione (boot storms) e  durante le scansioni dell’antivirus (anti-virus scanning storms) quando viene richiesta una grande quantità di blocchi storage in lettura con i medesimi contenuti.

Per maggiori informazioni è possibile:

Posted in View, VMware | Tagged | 1 Comment

VMware EUC Portfolio: novità in View 5.1

Posted on 3 maggio 2012 by Samuele

Il 2 maggio VMware ha annunciato il prossimo rilascio di VMware View 5.1, uno dei pilastri della suite dei prodotti VMware nell’area End User Computing, destinato a rendere a semplificare e rendere più agile la gestione dei desktop nell’era Post-PC.

VMware View 5.1 è stato rilasciato per potenziare le funzionalità del predecessore,  in particolar modo le aree di miglioramento riguardano:

I prodotti saranno disponibili nel Q2-2012

Per maggiori informazioni è possibile:

Posted in View, VMware | Tagged , , , | Leave a comment

VMware ThinApp 4.7.1: Release Notes

Posted on 2 maggio 2012 by Samuele

Il 26 Aprile VMware ha rilasciato ThinApp 4.7.1, aggiornamento che risolve una serie di bug. ThinApp è un prodotto che permette la virtualizzazione delle applicazioni e, nonostante esistano delle raccomandazioni per la creazioni delle bolle applicative, VMware non ha il controllo delle applicazioni rilasciate dagli ISV, è quindi possibile che vi siano casi specifici di insuccesso risolvibili dal team di VMware e dalle nuove release del prodotto.

I bug sono riassumibili in queste categorie:

  • comportamento inaspettato o mancanze all’interno dell’applicazione virtualizzata;
  • errori nell’esecuzione dell’applicazione virtualizzata;
  • errori nella compilazione

In questo articolo vengono citati alcuni dei problemi risolti:

  • Microsoft Word virtualizzato con ThinApp non legge i valori di registro per i parametri internazionali;
  • Accendendo ad una applicazione Web-based per l’invio della posta attraverso Internet Explorer 6 virtualizzato proporrà una lista dei destinatari di posta vuota;
  • Microsoft Office 2010 ora può essere distribuito su sistemi che hanno installato nativamente Office 2010;
  • i pacchetti licenziati con Virtual Microsoft KMS, possono ora funzionare insieme ad altri pacchetti licenziati attraverso il Virtual Microsoft KMS;
  • i pacchetti ThinApp supportano il protocollo SMB 2.0 per l’accesso alla sandbox tra i sistemi operativi Microsoft Windows 7, Windows Vista, Windows 2008 e Windows 2003;
  • un’applicazione ThinApp fallisce quando viene eseguita su un sistema Windows 7 e si imposta la posizione della sandbox in una share di un altro sistema Windows 7;
  • ThinApp non è in grado di avviare l’applicazione WordPad in un sistema Windows 7 virtualizzato;
  • su Microsoft Windows XP, l’applicazione Victor player non identifica i l formato file UDF nel CD presente nel drive, se virtualizzata con le precedenti versioni di ThinApp;
  • lanciando l’applicazione virtualizzata Visual Lighting su un host ESX o una Workstation 7 ed eseguendo una specifica funzione l’applicazione mostra l’errore: “Calculation-Error Message There is not enough virtual memory…”
  • aprendo uno shortcut Windows per una cartella da un’istanza virtualizzata di Internet Explorer 6 l’applicazione mostra l’errore CLASS_E_CLASSNOTAVAILABLE
  • su un sistema a 64 bit, aprendo un file PDF da Firefox virtualizzato su un ambiente a 32 bit , l’applicazione va in crash
  • su Microsoft Windows 7 quando si cerca di creare con ThinApp un pacchetto MSI più grande di 2 GB, la creazione fallisce con il seguente errore: “The system cannot open the device or file specified”

Anche per questa esistono delle “Known Issues” per le quali VMware rimanda alla propria Knowledge Base.

Per maggiori informazioni è possibile consultare la pagina relativa alle note di rilascio disponibile sul sito del produttore.

Posted in ThinApp, VMware | Tagged , | Leave a comment

Edizioni di vSphere e limiti sul Virtual SMP

Posted on 30 aprile 2012 by Samuele

Con vSphere è possibile creare una VM con 32 vCPU e 1 TB di vRAM, disponendo di una licenza Enterprise Plus come illustrato nella tabella di comparazione delle edizioni di VMware vSphere. Per quanto riguarda le altre edizioni il limite è di 8 vCPU per VM.

Nella tabella si parla sempre VM a 8 o 32 “way” il che può far sorgere qualche dubbio sul rapporto vCPU e vCore, soprattutto perché l’interfaccia grafica del vSphere Client permette di operare su entrambe i parametri; anche il documento relativo alle configurazioni massime parla di Virtual SMP anche se oggi con le architetture multi-core e hyper-threading sarebbe più opportuno parlare si SMT.

E’ quindi possibile creare una VM con più di 8 core senza una licenza Enterprise Plus? Come dimostrano le immagini riportate le risposta è negativa.

VM 2 vCPU 6 core

VM 2 vCPU 6 core

Errore nell'accensione dovuto ai limiti della licenza

Errore nell'accensione dovuto ai limiti della licenza

Posted in Parametri VM, VMware, vSphere | Tagged , , , | Leave a comment

Utilizzare vCops con vSphere Essentials, Essentials Plus o Standard

Posted on 23 aprile 2012 by Samuele

Il deployment della vApp di vCenter Operations Manager 5.0, richiede la presenza di un cluster con DRS oppure un host fuori dal cluster e gestito via vCenter, dato che la VAPP è anche un Resource Pool.

Errore nel deploy della vApp di vCops

Errore nel deploy della vApp di vCops

Visto che non è possibile creare i Resource Pool in un Cluster solo con vSphere HA questo escluderebbe l’uso di vCops per le edizioni Essentials Plus o Standard di vSphere, rendendolo un prodotto utilizzabile solo con le edizioni Essentials, Enterprise ed Enterprise Plus

Paradossalmente per l’edizione vSphere Essentials questo limite non si applica perché le vApp possono essere create anche sul singolo host (se agganciate ad un vCenter), mentre come anticipato i kit Essentials Plus e Standard includono le funzionalità di vMotion e vSphere HA ma non DRS

Questo articolo fornisce un workaround per l’uso di vCenter Operations Manager per gli ambienti che dispongono solo di un cluster con vSphere HA.

Per procedere è raccomandato avere almeno 3 host per evitare di interrompere, anche se temporaneamente, la copertura della protezione di HA. Come procedere:

  • rimuovere uno degli host dal cluster;
  • eseguire il deploy della vApp di vCenter Operations Manager, specificando l’uso di IP statici (l’uso di IP statici è un requisito per questo workaround);
  • ricollocare l’host con la vApp all’interno del cluster, operazione che mostrerà il warning relativo alla distruzione della vApp (ma non delle VM);
  • proseguire ignorando l’errore

Lo spostamento dell’host ESXi nel cluster, con la conseguente distruzione della vApp, ha portato ad avere nell’inventario del cluster2 VM, la “UI virtual machine” e la “Analytics virtual machine”. L’assenza “dell’involucro” offerto dalla vApp non impatta sul funzionamento di vCops, anche se alcune attenzioni sono richieste: ad esempio  sull’ordine di accensione e spegnimento delle VM, compito prima gestito dalla vApp.

Per la fase di spegnimento è necessario procedere con lo spegnimento della “UI virtual machine” aspettare 10 minuti e procedere con lo spegnimento della “Analytics virtual machine” eseguendo l’operazione inversa per la fase di accensione.

Per maggiori informazioni consultare la KB 2013695

Posted in vCenter Operations, VMware | Tagged , , | Leave a comment

vExpert 2012

Posted on 18 aprile 2012 by Samuele

Momento di autocelebrazione!

Anche se non ho ricevuto una mail ufficiale sembra che sia stato nominato vExpert per l’anno 2012. La prima persona a darmi la notizia è stato Andrea Mauro, VCDX  con-fondatore e membro del board  del VMUG IT, oltre che veterano vExpert.

La notizia è apparsa sul blog di VMware il 15 Aprile, anche se potrò crederci al 100% solo dopo aver ricevuto la mail da VMware; sinceramente spero proprio di non dover rettificare questo articolo.

Detto questo sono 9 gli italiani nella lista, tutte persone che ho la fortuna di conoscere e per le quali posso confermare la passione e la dedizione per quello che fanno oltre allo spessore tecnico, persone alle quali estendo le mie congratulazioni.

  • Andrea Mauro – vExpert 2010, 2011, 2012 – @Andrea_Mauro
  • Luca Dell’Oca – vExpert 2011, 2012 – @dellock6
  • Giuseppe Guglielmetti – vExpert 2011, 2012 – @gguglie
  • Fabio Rapposelli – vExpert 2011, 2012 – @fabiorapposelli
  • Piergiorgio Spagnolatti – vExpert 2011, 2012 – @drakpz
  • Massimo Re Ferrè – vExpert 2011, 2012 – @mreferre
  • Massimiliano Moschini – vExpert 2012 – @maxmoschini
  • Enrico Signoretti – vExpert 2012 – @esignoretti
  • Samuele Cerutti – vExpert 2012 – @samuelecerutti

Bene, momento di autocelebrazione terminato e soprattutto iniezione di motivazione per mantenere questo prestigioso titolo anche per il prossimo anno.

Posted in VMware | Tagged | 1 Comment

Utilizzare più NIC per VMotion

Posted on 11 aprile 2012 by Samuele

In un precedente articolo si era parlato dei miglioranti per VMotion con vSphere 5, in questo articolo si parlerà di come utilizzare più NIC per VMotion, non solo per ridurre il tempo necessario allo spostamento delle VM, ma anche per spostare VM di grandi dimensioni.

Se configurato adeguatamente ESXi può spostare le VM utilizzando più schede di rete; ovvero il servizio potrà sfruttare più initiator e più target durante lo spostamento, a patto che esistano più NIC sia sull’host di partenza che su quello di destinazione. Il primo task viene eseguito dal vCenter che controlla ogni host e determina la banda complessiva disponibile per VMotion, alcuni esempi:

  • se l’host di partenza ha 1 NIC da 1 GbE così come l’host di destinazione allora verrà aperta una sola connessione
  • se l’host di partenza ha 1 NIC da 1 GbE mentre l’host di destinazione ha 2 NIC GbE verrà comunque aperta una sola connessione
  • se l’host di partenza ha 3 NIC da 1 GbE mentre l’host di destinazione ne ha 1 da 10 GbE, allora verranno aperte 3 connessioni verso l’unica scheda dell’host di destinazione
  • se l’ho di partenza ha 15 NIC 1 GbE e quello di destinazione ha 1 NIC 10 GbE e 5 da 1 GbE allora 10 connessioni verranno aperte verso la sceda 10 GbE e altre 5 verso le schede rimenamenti per un totale di 15 connessioni.

Va ricordato che come best practices si dovrebbe evitare mix di NIC per un servizio (VMotion in questo caso) ma soprattutto gli host dovrebbero avere un layout, a livello di periferiche di I/O, simile fra d loro.

Per permettere a VMotion di sfruttare più NIC è necessario configurare opportunamente le porte VMkernel del Virtual Switch (vmknic) legandole a specifiche porte fisiche (vmnic). In caso di switch con team di schede sarà necessario lavorare a livello di portgroup puntando alla scheda “NIC Teaming”. Questa operazione è fattibile sia per gli standard Virtual Switch che per i Distribuited Virtual Switch (dvs)

VMkernel Port binding

VMkernel Port binding

Nell’immagine le NIC non legate alla porta VMkernel sono state spostare nell’area”Unused Adapters”, è anche possibile classificarle come “Standby Adapters”.

Con questa configurazione anche per lo spostamento di una VM verranno impegnate più NIC. Se si usano vengono utilizzati i dvs e non si hanno dei link dedicati a VMotion, è possibile prendere in considerazione l’uso della funzionalità Network I/O Control per prevenire che VMotion saturi tutta la banda a disposizione.

Per maggiori informazioni è possibile consultare:

 

Posted in vMotion, VMware | Tagged , | Leave a comment

Spegnere una VM attraverso la CLI

Posted on 6 aprile 2012 by Samuele

Lo spegnimento di una VM è un’attività abbastanza ordinaria che spesso viene eseguita direttamente dalla GUI del vSphere Client. In alcune condizioni è possibile che il comando di spegnimento lasci la VM in uno stato “ambiguo” nel quale non è concessa nessuna azione legata allo stato di power.

In questo articolo vengono analizzati 4 metodi per spegnere una VM con la linea di comando via ssh. Prima di procedere è necessario abilitare SSH sull’host ESXi attraverso la DCUI (Direct Console User Interface).

Uso del comando ESXCLI

  • Lanciare il comando “esxcli vm process list” per ottenere la lista delle VM che sono in esecuzione sull’host, magari aiutandosi con il comando grep per filtrare l’elenco indicando il nome della VM
  • Individuata la VM da spegnere eseguire il comando “esxcli vm process kill – -type=hard – -world-id=<World_ID>” ID trovato dal comando precedente

L’opzione –type  (oppure –t) ha le seguenti opzioni: hard, soft, force

Per maggiori informazioni sul comando è possibile accedere alla pagina d’aiuto del comando.

Uso del comando esxcli vm

Uso del comando esxcli vm

Uso del comando vim-cmd

  • Ottenere la lista delle VM accese sul server ESX lanciando il comando “vim-cmd vmsvc/getallvm”, anche in questo caso è possibile introdurre un filtro utilizzando grep
  • Dalla lista mostrata è necessario appuntarsi il Vmid della macchina che si desidera spegnere, lanciando il comando “vim-cmd vmsvc/power.off <Vmid>”

È possibile anche indagare sullo stato di power della macchina utilizzando il comando “vim-cmd vmsvc/power.getstate” oppure fare lo shutdown con il comando “vim-cmd vmsvc/power.shutdown”.

Uso del comando vim-cmd

Uso del comando vim-cmd

Uso del comando kill

L’uso del comando kill è sconsigliato in quanto si corre il rischio di chiudere un processo non appartenete alla VM.

  • Tutto inizia con l’esecuzione del comando “ps –u |grep <nome-vm>”, che rende la lista dei processi inerenti alla VM. La lista mostra l’ID del processo ed il Parent ID. L’esecuzione di un ulteriore comando si Process Status (ps) filtrato sul PID è fatto per maggiore sicurezza.
  • Accertati del PID di procede con il comando “kill <PID>”
uso del comando kill

uso del comando kill

Uso di esxtop

  • Come per il comando kill anche l’uso di esxtop per killare un processo è potenzialmente pericoloso. Lanciare “esxtop” e premere “f” per aggiungere il campo LWID (Leader World Id World Group Id) corrispondente alla lettera c. Individuata la VM da spegnere è necessario appuntarsi il codice LWID, premere la lettera k (kill) e immettere LWID.
Uso di esxtop

Uso di esxtop

Per maggiori informazioni è possibile consultare la KB 1014165

Posted in Command Line Interface, VMware | Tagged , , , , | Leave a comment