Cerca nel blog

martedì 30 marzo 2010

VMware Virtualization Forum


A Roma il 13 Aprile e Milano 15 Aprile, un occasione in piu per incontrarci fisicamente e fare due chiacchere.
Per info e registrazione seguite questo link www.vmware-forum.com/vforum



venerdì 26 marzo 2010

Installazione SRM-Shared Recovery Site

Riprendendo l’articolo Site Recovery manager: modalità “Shared Recovery Site”, questo articolo affronta i passi necessari per l’installazione.

Cominciamo con il mostrare l’architettura della soluzione.

Architettura SRM in modalità Shared Recovery Site

Come si nota dal diagramma per ogni “cliente” del sito di disastro condiviso, è necessario installare SRM sia presso il sito protetto sia presso il sito di DR. Ogni installazione di SRM nel sito DR condiviso dovrà avvenire su di un host dedicato sia esso fisico o virtuale. Non è possibile installare istanze multiple di SRM su di un singolo host.

Per sfruttare la feature “Shared Recovery Site” è necessario utilizzare delle “Custom Extensions ID”, è quindi necessario procedere con l’installazione del pacchetto SRM attraverso la linea di comando. La sintassi per l’installazione è simile alla seguente:

"SRM Installer.exe" /V"CUSTOM_SETUP=1

In questo modo il wizard fornisce degli ulteriori step non presenti nell’installazione di base. Le dialog aggiuntive servono a:
  • specificare il tipo di “VMware vCenter Site Recovery Manager Plugin Identifier”, dove è necessario scegliere"custom";
  • inserire le informazioni per il “Custom SRM Plugin Identifier”, informazioni necessarie per il pairing tra siti.
Dialog aggiuntive per l'installazione custom di SRM

A questo punto nel SRM presente nel vCenter del sito di recovery verrà presentata la possibilità di collegarsi a più istanze, una per ogni SRM ID gestito dal vCenter.

Per maggiori informazioni e per una guida video sull’argomento è possible consultare la KB 1014640

mercoledì 24 marzo 2010

Site Recovery manager: modalità “Shared Recovery Site”

VMware vCenter Site Recovery Manager (SRM) viene tipicamente utilizzato per proteggere un’istanza specifica di vCenter. Questo avviene accoppiando il vCenter del sito secondario con quello che deve essere protetto, ovvero il vCenter del sito primario.

Interconnessione tra 2 vCenter

L’istanza del sito primario viene configurata per fare failover sull’istanza secondaria e, sotto il controllo del piano di DR, in caso di disastro SRM:
  • elegge il sito remoto ad assumere il controllo di tutti i servizi erogati dal sito primario;
  • aggiunge tutte le macchine virtuali protette nel sito primario al sito di DR;
  • riaccende le VM secondo l’ordine stabilito
Questa relazione 1 a 1 può essere:
  • monodirezionale, secondo la logica sito “attivi/primario” sito “passivo/DR”;
  • bidirezionale, ovvero che i due siti si proteggono reciprocamente;
SRM 4.0 dispone della feature “sito DR condiviso” (Shared Recovery Site Support) che permette l’accoppiamento “molti a uno” (many‐to‐one pairing) dove molti sono i siti da proteggere e uno è il sito DR.

Gli scenari appartenenti a questa tipologia sono caratteristici di quelle aziende che desiderano proteggere più uffici periferici in un unico sito, oppure quando un’azienda intende fornire il servizio di DR a più clienti condividendo l’infrastruttura a disposizione.

Per maggiori informazioni consultare il documento: "Installing, Configuring, and Using Shared Recovery Site Support"

martedì 23 marzo 2010

VMware ThinApp 4.5: Nuova tool RELINK.exe e considerazioni

Con la nuova versione 4.5 di ThinApp e' stato introdotto un nuovo strumento chiamato relink.exe.

Relink.exe e' in grado di iniettare (letteralmente) un nuovo runtime di ThinApp in un pacchetto già esistente.

Questo rende la necessità di una re-build completa del progetto obsoleta, fighissimo quando ad esempio quando è necessario aggiornare il runtime per fornire il supporto di Windows 7.

Bisogna fare pero un paio di considerazioni:

L'ottimizzazione in memoria e performance introdotta con la versione 4.5 utilizza il parametro "OptimizeFor =" nel package.ini.
Il re-build utilizzerà il default "OptimizeFor = Memory", ovvero l'ottimizzazione per le prestazioni, se non specificato diversamente in package.ini.
Il relink.exe invece usato su un pacchetto esistente utilizzerà la vecchia configurazione della 4.0.x, quindi le performance sono le stesse del parametro "OptimizeFor = disk"  nel package.ini.
Quindi se si desidera utilizzare l'ottimizzazione per le prestazioni/memoria si deve ricostruire (re-build) il progetto.

Inoltre utilizzando relink.exe su un pacchetto esistente onorerà le impostazioni predefinite, quindi anche la nuova funzionalità di Quality Reporting utilizzera' l'impostazione "QualityReportingEnabled = 0" e non verranno inviati dati di reportistica anonima... anche se son sicuro che molti di voi non l'attiveranno comunque ;-)

Stay updated, Stay tuned,
Sivix.

Cluster DRS: inversione dei livelli di raccomandazione

Il cluster VMware DRS (Distributed Recourse Scheduler) permette di bilanciare dinamicamente le risorse fisiche (CPU e memoria) a disposizione del cluster, tra le VM attraverso una continua osservazione ed in base ai parametri di consumo impostati nei re source pool e nelle risorse delle VM stesse.

DRS permette di gestire il bilanciamento sia in modalità manuale che automatica avvalendosi di raccomandazioni generate dal software stesso. Tali raccomandazioni sono visibili nella scheda “DRS” puntando all’oggetto cluster nell’inventario “Hosts & Clusters”.

Scheda "DRS" dell'oggetto Cluster

Dalla versione 3.x a vSphere i criteri per stabilire le priorità sono cambiati, infatti mentre in VMware Infrastructure 3 la priorità maggiore è dato dal punteggio a 5 stelle, in vSphere la priorità più alta è “Priority one”

Il livello più alto di raccomandazione è riconducibile ad un evento che obbliga lo spostamento della VM, ad esempio quando un host sta andando in manutenzione, in stand-by oppure c’è una violazione nelle regole impostate nel cluster DRS. Le altre priorità indicano quanto la raccomandazione potrebbe apportare benefici alle performance dell’intero cluster; da 2. ovvero miglioramento significativo, a 5 ovvero leggero miglioramento.

Tra le ragioni per lo spostamento delle VM abbiamo:
  • bilanciare il cacico medio della CPU o della memoria;
  • soddisfare un regola di affinità o di anti-affinità imposta nel cluster;
  • entrata di un host in manutenzione;
  • diminuzione del consumo di energia elettrica;
  • spegnimento di uno specifico host;
  • incremento della capacità del cluster.

Per maggiori informazioni consultare il documento DRS Recommendations Page.

lunedì 22 marzo 2010

VCB: End of Life, ma con l’aggiornamento

VMware Consolidated Backup (VCB) è stato il prodotto/framework di riferimento, in VMware, per il backup delle macchine virtuali a partire dalla versione 3.x della VMware Virtual Infratstructure . Il software può essere installato su un server fisico o virtuale, definito proxy backup, per centralizzare tutte le operazioni di back riducendo il carico di lavoro degli host ESX.

Diversi blog hanno annunciato, sulle rispettive pagine, che il prodotto ha terminato il suo ciclo di vita (EOL) mentre sulle pagine del sito del vendor, si evince che il futuro del backup non consiste in un ulteriore sviluppo di VCB. Per un approfondimento è possibile consultare i seguenti due link:
Detto questo, VCB al momento è supportato sia su piattaforma VI3 sia su vSphere 4.x. L’11 di Marzo, inoltre, VMware ha rilasciato un aggiornamento riguardante il prodotto. Si tratta di un update che non porta nuove features ma corregge alcuni problemi noti:
  • il Backup delle VM con il commando “vcbmounter -M1” necessita di più tempo: il problema si riferiva al salvataggio delle VM con VMDK più grandi di 50 GB esportati in formato monolitico (-M1);
  • backup full delle VM con il comando vcbMounter fallisce con un messaggio d’errore: il problema, risolto dall’update si verificata se il commando veniva lanciato dal vCenter Server;
  • viene visualizzato un messaggio d’errore incorretto durante il backup delle VM via rete (modalità NBD): il problema si manifestava in caso di perdita della rete durante la fase di mount della VM per il full backup. “Il messaggio ora mostrato è “Failed to export the disk: Probably network disruption”.
Maggiori informazioni possono essere reperite alla pagina delle release notes del prodotto.

giovedì 11 marzo 2010

vCenter 4: Linked Mode e ADAM

Con l’arrivo di vSphere e quindi di Vcenter 4, VMware ha introdotto la modalità Linked Mode. Questa modalità serve per collegare più vCenter fra di loro permettendo di fatto di:
  • gestire attraverso il vSphere Client fino a 10 vCenter collegati;
  • scalare il numero massimo di VM e Host gestibili dall’ambiente (fino a 1000 host e 15000 VM Registrate)

La modalità Linked mode si avvale di ADAM, Active Directory Application Mode, che grazie, alle sue features, permette di replicare tra i vCenter confederati le seguenti informazioni:
  • lista delle istanze vCenter che partecipano al gruppo;
  • definizione dei ruoli, quindi delle autorizzazioni
  • gestione delle licenze disponibili e relativa assegnazione, avendo quindi una gestione centralizzata per tutti i vCenter del gruppo.
Per utilizzare la modalità linked mode il vCenter server dovrà avere determinati prerequisiti:
  • non dovrà essere un Domain controller ma partecipare, ovvero essere server membro di una Active Directory:;
  • l’utente utilizzato dovrà essere un utente di dominio ed essere membro dell’Admin group
  • l’istanza dovrebbe appartenere ad un singolo dominio oppure avere un trust a due vie
  • i nomi della macchina deve corrispondere al nome inserito nel DNS server appartenenti al gruppo
Le opzioni Linked mode sono selezionabili in fase di installazione del vCenter stesso:
  • "Create a standalone vCenter instance": opzione destinata per l’installazione del primo vCenter che formerà il gruppo oppure per un vCenter stand alone
  • "Join a vCenter Group using linked mode to share information": opzione designata, per aggiungere un secondo vCenter ad una istanza già generata

vCenter Linked Mode Options

Per maggiori informazioni consultare la KB1017480.

mercoledì 10 marzo 2010

Come inviare i log degli host ad un syslog server remoto

Se in azienda è presente un server deputato a ricevere i log di sistema di tutti gli apparati dell’infrastruttura può essere utile, se non indispensabile, adeguare a tale comportamento anche i server ESX.

ESX ed ESXi si comportano in modo diverso per la gestione dei log, di seguito l’elenco dei log scritti dal sistema:

  • /var/log/messages: log del sistema operativo (ESX/ESXi)
  • /var/log/vmware/hostd.log: log dell’agente ESX ”Hostd” (ESX/ESXi)
  • /var/log/vmware/vpx/vpxa.log: log dell’agente vCenter (ESX/ESXi)
  • /var/log/vmkernel: log del VMkernel (solo ESX)
  • /var/log/vmkwarning: log dei warning relativi al VMkernel (solo ESX)

Entrambe le tipologie di server (ESX ed ESXi) utilizzano un processo syslog per scrivere i propri log. Il servizio legge le configurazioni in /etc/syslog.conf per determinare cosa e dove scrivere le informazioni. Il file /etc/syslog.conf può essere può essere modificato per tracciare i log su file locali oppure per l’invio delle informazioni ad un server remoto o entrambe le cose. Per ESX la modifica può essere più complessa rispetto ad ESXi.

Il file syslog.conf è un file di testo contenente le informazioni in stile tabellare con 2 colonne. La prima colonna contiene un selettore (Selector) mentre la seconda contiene l’azione.

Un esempio generico della sintassi della stringa:

facility.priority /<percorso del file>,oppure <@hostname> oppure <@Indirizzo IP>,


Il selettore è una stringa di testo strutturata come “facility.priority”. La facility è il servizio che si desidera “loggare” mentre la priority indica appunto la priorità. Il VMkernel è programmato per utilizzare la facility “local6”.

L’azione contiene le informazioni relative “al dove” scrivere il log.

Un esempio della stringa (invia i warning del VMkernel al file /var/log/vmkwarning):

local6.warning /var/log/vmkwarning

Oltre alla modifica al fine sono necessarie alter operazioni:

  • apertura delle porte del firewall (via GUI) oppure con il comando: "esxcfg-firewall –o 514,out,udp,syslog_traffic"
  • Riavviare il servizio syslog con il comando: service syslog restart

Per inviare i log ad un server remoto, in ESXi è anche possibile utilizzare il command
  • vicfg-syslog –s <IP_address_of_log_host>

Per maggiori informazioni consultare la "Basic System Administration Guide"

martedì 9 marzo 2010

VMware Labs

VMware ha reso disponibile un nuovo sito contenente articoli, documenti, commenti e più generalmente informazioni relative a prodotti e servizi VMware e non. Lo scopo del sito è quello di fornire un luogo si scambio di opinioni per tutti gli utenti interessati alle tecnologie di virtualizzazione.

I prodotti presentati vengono forniti AS-IS e non c'è alcuna garanzia che i progetti inseriti nel sito diventeranno prodotti del portafoglio VMware.

Al momento sono presenti i seguenti progetti:

  • Apache Pivot: si tratta di una piattaforma open-source per creare applicazioni Internet, rich internet application (RIA). Le applicazioni scritte con Pivot utilizzano una combinazione di linguaggio Java, da cui deriva la solidità della piattaforma, e codice XML. Dato che il web rappresenta uno standard de facto per la distribuzione di applicazioni, le applicazioni RIA rappresentano un ottimo compromesso tra le applicazioni HTML, che offrono una scarsa user experience, e le applicazioni tradizionali che devono essere installate localmente;

  • Dynamo RIO: è un software che consente la manipolazione di codice durante la sua esecuzione. DynamoRIO fornisce una via efficiente, trasparente e completa per il controllo di applicazioni che girano sia su Windows che su Linux su piattaforma IA-32 e AMD64;

  • Esxplot: software che gira su piattaforma linux e fornisce un’interfaccia grafica per la lettura dei dati generati dal comando esxtop in modalità batch. L’applicazione fornisce inoltre gli strumenti di ricerca per poter individuare i contatori più rilevanti ed è in grado di disegnare nello stesso grafico le metriche di contatori differenti. Questa applicazione nasce per sopperire alla difficoltà di gestione dei dati con Excel e con il performance monitor dei sistemi Microsoft;

  • Onyx: applicazione, client side, che è in grado di catturare le informazioni generate dall’attività tra il vSphere client e il vCenter Server per convertirli in script PowerShell. Sull'argomento consultare anche il post "VMware Project Onyx";

  • SVGA Sonar: applicazione demo per SVGADevTap. SVGADevTap è una libraria, livello utente, che comunica con il driver VMware SVGA, driver che gira a livello di Guest OS. Sonar è stato progettato per utilizzare le API di devtap. I campi di applicazione dello strumento devono essere ancora chiarire;

  • vApprun: si tratta di uno strumento utilizzabile via command line che porta in VMware Workstation e Fusione le features delle vAPP utilizzate in vSphere, ovvero il concetto di applicazione distribuita tra più VM che possono essere gestite attraverso diverse policy (accensione e spegnimento coordinati, per fare un esempio). Con questo strumento sia VMware Workstation sia Fusion possono essere utilizzati quali piattaforme: di sviluppo e creazione di pacchetti OVFma anche per valutazione e test di pacchetti OVF esistenti;

  • vCMA: VMware vCenter Mobile Access (vCMA) permette di gestire un'infrastruttura VMware dal proprio cellulare grazie ad un’interfaccia ottimizzata per questo tipo di device. Per poter accedere a vCMA, è necessario distribuire una virtual appliance chiamata vCMA server. Il vCMA server deve essere collegato al vCenter Server o direttamente ai server ESX che si intendono gestire;

  • VGC: è un’applicazione capace di interagire con il sistema operativo installato nelle macchine virtuali. VGC include una serie di strumenti quali: Unified Task Manager, Guest file system explorer, Snapshot Manager e VM Manager. VGC supporta vSphere, Server 2.0, Workstation e può collegarsi a più host simultaneamente;

  • VI Java: Sphere Java API si tratta di una serie di librerie Java che che si appoggiano agli SDK dei Web services forniti da vSphere. Il prodotto permette di gestire e controllare sia i server che le VM;

  • Virtual USB Analyzer: Strumento che permette di eseguire il debug delle periferiche USB all’interno dello stack di virtualizzazione. Virtual USB Analyzer non è un tool che “sniffa” le informazioni che passano sulla porta USB, è un’interfaccia grafica che permette all’utente di visualizzare log dei pacchetti USB.


Per maggior informazioni potete consultare:

lunedì 8 marzo 2010

Ready...Set...VMware Go!

Per tutti gli utneti di ESXi da qualche tempo esiste un tool di management messo a disposizione da VMware, sviluppato in collaborazione con Shavlik Technologies, chiamato VMware Go.

VMware Go è un software web-based che fornisce, alle piccole aziende che hanno limitate risorse per la gestione dell’infrastruttura IT, tutto il necessario per iniziare il viaggio verso la virtualizzazione, automatizzando le operazioni di installazione e configurazione con pochissimi click del mouse.

I punti chiave del prodotto sono:

  • interfaccia web intuitiva, anche se disponibile solo in lingua inglese;

  • installazione e configurazione pilotata attraverso una semplice procedura guidata;

  • integrazione degli strumenti per la verifica della compatibilità hardware, per facilitare la scelta dei server su cui virtualizzare;

  • accelera la creazione di server ESXi e l’aggiunta di VM

  • gestione centralizzata e montitoraggio di server ESX’ e relative macchine virtuali


Il prodotto viene supportato attraverso la community di VMware. Per quanto riguarda ESXi, oltre alla community ed il "Product Support Center" disponibili via web, è possibile contrattualizzare il supporto oppure acquistare il supporto per incidente.

Per iniziare ad utilizzare il prodotto VMware necessita di installare alcune componenti:

  • Discovery Application, software sviluppato da Shavlik Technologies

  • Windows PowerShell

  • .Net Framework

  • vSphere Power CLI

  • VMware Standalone Converter

  • VMware Remote Console


Per maggiori informazioni consultare la KB 1017282.

sabato 6 marzo 2010

ESX 4.0 e dead keys

La pressione dei tasti Ctrl+Alt+Del nella service console di ESX 4.0, causa l’arresto della macchine virtuali e il reboot dell’host, indipendentemente che il suo stato sia in modalità di manutenzione oppure no.

Per risolvere il problema è possible:

  • applicare la patch ESX400-201002402-BG

  • editare il file /etc/inittab


Se si opta di modificare il file, una volta ottenuto l’accesso come root, utilizzando un editor di testo come nano o vi è necessrio operare come segue:

  • cercare l’istruzione “ca::ctrlaltdel:/sbin/shutdown -t3 -r now”;

  • commentare il comando aggiungendo un “#” ad inizio riga, dopo la modifica l'istruzione dovrebbe apparire come segue “# ca::ctrlaltdel:/sbin/shutdown -t3 -r now”;

  • slavare il file appena modificaro

  • forzare il sistema a rileggere il file /etc/inittab esguendo il comando “init q”


Per maggiori informazioni consultare la KB 1018950.

Utilizzare il controller SCSI paravirtualizzato (PVSCSI) nelle VM

Con vSphere 4, o meglio con ESX 4, oltre ai già presenti BusLogic e LSI Logic (Parallel) sono stati inseriti due ulteriori tipi di controller SCSI, LSI Logic SAS e VMware Paravirtual (PVSCSI).

La selezione del tipo di controller SCSI avviene nella fase di creazione della VM (custom) oppure cambiando la tipologia di controller nei parametri della VM.
Controller PVSCSI

Il controller PVSCSI è un controller SCSI ad alte prestazioni che in grado di generare grandi senza consumi di CPU. Questo controller si adatta meglio per quegli ambienti dove l’hardware o le applicazioni generano una grande quantità di I/O.

Il controller SCSI Paravirtualizzato è supportato per i seguenti guest OS:

  • Windows Server 2008

  • Windows Server 2003

  • Red Hat Enterprise Linux (RHEL) 5


Se da un lato il controller PVSCSI offre le prestazione, dall’altro le seguenti limitazioni:

  • Hot add o hot remove necessitano un bus rescan nel guest OS;

  • la presenza di snapshot potrebbe compromettere il guadagno di performance, scegliendo dischi VMDK indipendenti si aggira il problema;

  • se l’host è in condizioni di memoria overcommitted il guadagno di performance può essere compromesso;

  • aggiornando RHEL 5 è possibile incorrere in un Kernel non supportato con la conseguente perdita di accesso al disco che utilizza il controller paravirtualizzato (problema risolvibile lanciando vmware-config-tools.pl);

  • l’aggiunta a caldo (hot add) del controller PVSVSI non è suppotata, questo perché di default la tipologia di controller aggiunto dalla procedura dipende da quella del controller del disco di boot;

  • per le VM linux il boot da device PVSCSI non è supportato,il controller è utilizzabile per i dischi dei dati;

  • per le VM windows il boot da device PVSCSI non è supportato nelle versioni precedenti di ESX 4.0 U1.


Per maggiori informazioni consultare la KB 1010398.

giovedì 4 marzo 2010

Enhanced VMotion Compatibility ed i parametri del BIOS

Enhanced VMotion Compatibility (EVC) è una features introdotta da VMware a partire da ESX 3.5 Update 2 con vCenter 2.5 Update 2 o superiori. Lo scopo promario di EVC è quello di correggere eventuali problemi legati a VMotion quando nel proprio cluster DRS ci sono server con CPU di generazioni differenti.

EVC automaticamente configura le CPU dei server sfruttando le tecnologie “Intel FlexMigration” o “AMD-V Extended Migration” per la retro compatibilità con CPU di server meno recenti.

EVC viene abilitato durante la creazione automatica del Cluster nell’inventario vCenter, dando all’amministratore la possibilità di specificare la baseline predefinita per il cluster.

Wizard Enhanced VMotion Compatibility

Lo scopo della baseline è quello di:

  • presentare tutti gli host appartenenti al cluster come un set di CPU aventi le medesime features, assicurando la mobilità delle VM con VMotion;

  • evitare l’ingresso nel cluster di host ESX i cui processori non rientrano nella baseline specificata.


Il match tra CPU dell’host e la baseline del cluster avviene solo nel momento in cui ESX viene aggiunto al cluster, quindi un’attività di manutenzione straordinaria ad un host già appartenente ad un cluster potrebbe compromettere i vantaggi per cui EVC è stato progettato. Attività come cambio di motherboard o applicazione di firmware potrebbe provocare modifiche ai parametri del BIOS portando al problema appena descritto, parametri come:

  • Istruzioni "hardware virtualization" (AMD V oIntel VT), che devono essere abilitati;

  • AMD No eXecute (NX) oppure Intel eXecute Disable (XD), funzione che deve essere abilitata;


Per maggiori informazioni sulla compatibilità dei processori per EVC consultare la KB 1003212.
Per maggiori informazioni sui problemi incontrati con EVC in relazione ai parametri del BIOS consultare la KB 1018756.

mercoledì 3 marzo 2010

VMware Project Onyx

Project Onyx è un nuovo tool capace di generare codice registrando le azioni compiute nel vSphere client, semplicemente con i click del mouse.

Si tratta di un software client side che, come un registratore di Macro, converte le richieste fatte al vSphere client in codice PowerShell. Il prodotto usa le stesse API usate da VMware ed è in grado di registrare tutte le operazioni svolte nella GUI indipendentemente dalla difficoltà.

Questo tool viene incontro alle esigenze degli utenti che intendono iniziare a sviluppare script di automazione per vSphere e, considerando che le API in vSphere sono uno strumento potentissimo ma la presenza di diversi documenti sparsi, l'assenza di un corso specifico e di best practices, ne rendono difficile il loro utilizzo.

Per dare qualche dato, le API di vSphere dispongono di oltre 450 funzioni, molte delle quali hanno parecchie proprietà. Ad esempio la riconfigurazione della VM (ReconfigVM) dispone di 305 proprietà.

Dato che il codice prodotto è il risultato di operazioni registrate dalla GUI, è necessario mettere mano al codice per:

  • pulire gli elementi "hard coded", come gli ID degli oggetti usati nella registrazione;

  • eliminare l'eventuale codice generato, ma non necessario ai fini dello script;

  • aggiungere della logica a supporto dello script stesso.


Come anticipato la creazione di script risulta semplicissima anche per chi non ha alcuna esperienza di programmazione, in quanto l'attività svolta nel vSphere client si trasforma in codice PowerShell, successivamente editabile ed integrabile in ulteriori script.

Il prodotto è ancora in fase di sviluppo e le informazioni disponibili al momento sono reperibili al seguente URL: http://vmware.com/go/onyx.