In questo ultimo e definitivo articolo, voglio condividere metodi alternativi di distribuzione di nodo di gestione vCenter Server di utilizzare l'apparecchio VCSA 6.0. Date un'occhiata ai vari metodi di distribuzione di seguito e le relative istruzioni per maggiori dettagli. Se si distribuisce utilizzando uno degli script qui sotto, è necessario estrarre il contenuto del VCSA ISO. Se si sta distribuendo a Workstation / Fusion, è necessario estrarre il VCSA ISO e aggiungere l'estensione .ova al seguente file VMware-VCSA-all-6.0.0-2562643-> vcsa-> vmware-vcsa prima della distribuzione. Disclaimer : Anche se queste opzioni di distribuzione alternative funzionano, sono, tuttavia, non ufficialmente supportati da VMware. Si prega di utilizzare a proprio rischio.
vcsa-mgm-node
Distribuzione di un server vCenter esistente utilizzando ovftool (script di shell)
Ho creato uno script di shell chiamato deploy_vcsa6_mgmt_to_vc.sh che richiede l'utilizzo di ovftool 4.1 (incluso nel VCSA ISO) per specificare le opportune OVF "guestinfo" proprietà di una distribuzione Node Management vCenter Server. Sarà necessario modificare lo script e modificare diverse variabili in base al proprio ambiente.
Ecco un esempio di esecuzione dello script:
vcsa-6.0-vCenter-server-gestione-distribuzione
Distribuzione di un host ESXi usando ovftool (script di shell)
Ho creato uno script di shell chiamato deploy_vcsa6_mgmt_to_esxi.sh che richiede l'utilizzo di ovftool 4.0 o superiore per specificare le opportune OVF "guestinfo" proprietà di una distribuzione vCenter Server Management Node. Sarà necessario modificare lo script e modificare diverse variabili in base al proprio ambiente. Il comportamento di questo script è simile a quello di cui sopra, ad eccezione si sta distribuendo direttamente a un host ESXi.
Distribuzione di un server vCenter esistente utilizzando ovftool (PowerCLI)
Ho creato uno script chiamato PowerCLI Deployment-VCSA-Mgmt.ps1 che utilizza ovftool e specifica le opportune OVF "guestinfo" proprietà di una distribuzione Node Management vCenter Server. Sarà necessario modificare lo script e modificare diverse variabili in base al proprio ambiente.
Distribuzione di VMware Fusion e Workstation
Per distribuire correttamente il nuovo VCSA 6.0, è necessario impostare la proprietà corretta OVF prima l'avvio della VM. Poiché VMware Fusion e Workstation non supportano le proprietà OVF, è necessario distribuire manualmente il VCSA, ma non accenderlo. Una volta che la distribuzione è terminato, è necessario aggiungere le seguenti voci nel file VMX del VCSA e sostituirlo con le impostazioni dell'ambiente. Dopo aver salvato le modifiche, è possibile accendere il VM e le configurazioni verranno lette nella VM per la configurazione iniziale.
guestinfo.cis.deployment.node.type = "gestione"
guestinfo.cis.system.vm0.hostname = "192.168.1.50"
guestinfo.cis.vmdir.domain-name = "vghetto.local"
guestinfo.cis.vmdir.site -name = "vghetto"
guestinfo.cis.vmdir.password = "! VMware1"
guestinfo.cis.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.addr = "192.168.1.64"
guestinfo. cis.appliance.net.pnid = "192.168.1.64"
guestinfo.cis.appliance.net.prefix = "24"
guestinfo.cis.appliance.net.mode = "statici"
guestinfo.cis.appliance.net.dns.servers = "192.168.1.1"
guestinfo.cis.appliance.net.gateway = "192.168.1.1"
guestinfo.cis.appliance.root.passwd = "VMware1!"
guestinfo.cis.appliance.ssh.enabled = "true"
guestinfo. cis.appliance.ntp.servers = "0.pool.ntp.org"
Per ulteriori informazioni, potete dare un'occhiata a questo articolo qui .
Distribuzione con nuovo sostenuto script di installazione (bonus)
Come accennato in precedenza, vi è anche un nuovo installer script incluso all'interno del VMware-VCSA ISO sotto / vcsa-cli-installer che supporta Windows, Mac OS X e Linux, ma deve essere collegato direttamente a un host ESXi. Ci sono diversi modelli che sono inclusi anche all'interno delle / vcsa-cli-installer / templates . Ho pensato come bonus Vorrei anche condividere il modello ho usato per distribuire le istanze PSC replicati utilizzando un indirizzo IP statico che alcuni di voi potrebbero trovare utili.
"__comments":
[
"William Lam - www.virtuallyghetto.com",
"Example VCSA 6.0 vCenter Server Management Node Deployment w/Static IP Address"
],
"deployment":
{
"esx.hostname":"192.168.1.200",
"esx.datastore":"mini-local-datastore-1",
"esx.username":"root",
"esx.password":"vmware123",
"deployment.option":"tiny",
"deployment.network":"VM Network",
"deployment.option":"management-tiny",
"appliance.name":"vcsa-mgmt-node",
"appliance.thin.disk.mode":true
},
"vcsa":
{
"system":
{
"root.password":"VMware1!",
"ssh.enable":true,
"ntp.servers":"0.pool.ntp.org",
"platform.service.controller":"192.168.1.50"
},
"sso":
{
"password":"VMware1!",
"domain-name":"vghetto.local",
"site-name":"virtuallyGhetto"
},
"networking":
{
"ip.family":"ipv4",
"mode":"static",
"ip":"192.168.1.52",
"prefix":"24",
"gateway":"192.168.1.1",
"dns.servers":"192.168.1.1",
"system.name":"192.168.1.52"
}
}
}
L'utilizzo del programma di installazione di script, basta cambiare nella directory piattaforma OS appropriata (win32, mac o lin64) e ci dovrebbe essere un binario chiamato vcsa-deploy. Per utilizzare questo modello, è sufficiente salvare il JSON in un file e quindi specificare che come primo argomento a vcsa-distribuire utility.
Ecco un esempio di distribuzione di un PSC utilizzando il vcsa implementare installer script.
vcsa-6.0-vCenter-server-gestione-node script-installazione
Parte 0: Introduzione
martedì 24 marzo 2015
giovedì 5 marzo 2015
Duplicate MAC preoccupazioni indirizzo con XVC-vMotion a vSphere 6.0
In vSphere 6.0, le opzioni di mobilità per una macchina virtuale è veramente senza limiti. Questo è stato possibile con una nuova serie di funzionalità vMotion introdotti in vSphere 6.0, che si può imparare di più su di loro qui e qui . In passato, una zona di preoccupazione durante la migrazione di una macchina virtuale da un vCenter Server a un altro è la possibilità che MAC Address di un VM migrato potrebbe essere re-provisioning dal server di origine vCenter conseguente conflitto di indirizzo MAC. In realtà, questo è in realtà un argomento che ho coperto prima nelle mie considerazioni durante la migrazione di macchine virtuali tra i server vCenter articolo. Altamente incoraggio controllare che l'articolo prima di procedere ulteriormente in quanto fornisce un contesto aggiuntivo e necessario.
Quando si cerca di sfruttare la nuova croce vCenter Server vMotion (XVC-vMotion) capacità di vSphere 6.0, sono MAC Address conflitti ancora una preoccupazione? Per rispondere a questa domanda, consente di dare un'occhiata a un esempio. Qui di seguito ho un grafico raffigurante due differenti distribuzioni vSphere 6.0. Il primo è composto da tre server vCenter che hanno aderito allo stesso dominio SSO chiamato vghetto.local e VM1 è attualmente gestito da VC1. Il secondo è un singolo server vCenter collegato ad una completamente diversa SSO Dominio chiamato vmware.local. Io anche assumere siamo messi bene Admin VI e abbiamo implementato ogni vCenter Server utilizzando un ID univoco (maggiori dettagli qui sul perché avere diverse questioni ID VC).
mac-address-XVC-VMotion-00
Consente di dire che siamo ora migrare VM1 da VC1 a VC2. Nelle versioni precedenti di vSphere, questo potenzialmente potrebbe portare a VC1 re-provisioning l'indirizzo MAC che VM1 è stato associato con perché Indirizzo MAC non era più gestito da VC1 e dal suo punto di vista, è ora disponibile. Anche se questo tipo di scenario è probabilmente rara nella maggior parte degli ambienti dei clienti, in un alto tasso di abbandono integrazione continua o ambiente erogazione continua, questo può essere un problema reale. Così è stato migliorato nulla in vSphere 6.0? La risposta è sì, ovviamente:)
In vSphere 6.0, vCenter Server ora mantiene un indirizzo Blacklist VM MAC che su un successo XVC-vMotion aggiornerà questa lista nera con gli indirizzi MAC associati al VM migrato. Questo assicura che il server di origine vCenter non si ri-provisioning questi indirizzi MAC per appena creato macchine virtuali e questi indirizzi MAC sono fondamentalmente "lista nera" di essere utilizzato di nuovo come mostrato nella figura seguente.
mac-address-XVC-VMotion-1
Se decidiamo di migrazione VM1 dal VC2 torna VC1, la lista nera viene aggiornata automaticamente e "lista nera" Indirizzi MAC verrà rimosso. Se decidiamo di migrare VM1 a un server completamente diverso vCenter che non fa parte dello stesso dominio SSO, l'indirizzo MAC potrebbe potenzialmente essere riutilizzato, ma dipenderà dal vostro ambiente se VC4 è su un segmento L2 completamente diverso, allora non si sarebbe verificato un conflitto Indirizzo MAC.
A partire da ora, non c'è modo automatico della bonifica lista nera indirizzi MAC, si tratta di un processo manuale che deve essere avviata attraverso una API vSphere privato. Spero che saremo in grado di ottenere questo documentato in un funzionario VMware KB, in modo che in caso questo è necessaria, si può facilmente seguire i semplici passaggi per eseguire le API necessarie. Recupero automatico è stato guardato da Engineering e speriamo di vedere questo in un futuro patch / aggiornamento in vSphere. Nel complesso, questo non dovrebbe in realtà dovrebbe essere una preoccupazione dato che vCenter Server può generare in modo univoco circa 65.000 unici indirizzi MAC e si dovrebbe fare un bel po 'XVC-vMotions prima mai dover recuperare dalla lista nera.
Una cosa da tenere presente quando si esegue XVC-vMotion o EXVC-vMotion è che attualmente non vi sono controlli pre-volo per MAC conflitti di indirizzo del server di destinazione vCenter (qualcosa di Ingegneria è alla ricerca di aggiornamento in un futuro patch / versione di aggiornamento). Detto questo, ci sono due ulteriori misure si possono attuare in voi ambiente per prevenire conflitti MAC Address:
Crea allarme vCenter Server in grado di rilevare e notificare un duplicato MAC Address in voi ambiente (applicabile anche a vSphere 5.5)
Controllare proattivamente per vedere se gli indirizzi MAC esistenti del vostro VM è attualmente in uso prima di eseguire un XVC-vMotion, questo è particolarmente utile quando si eseguono EXVC-vMotion .
Per aiutare con con il numero 2, ho creato un semplice script PowerCLI chiamato check-vm-mac-conflict.ps1 che accetta sia la sorgente e la destinazione vCenter Server, nonché il nome del VM nel VC di origine da migrare. Controllerà indirizzi MAC del VM nel VC destinazione e garantire che non vi siano conflitti. Se c'è un conflitto, il risultato sarà il nome della destinazione VM e l'indirizzo MAC che è in conflitto come si vede nello screenshot qui sotto.
mac-address-XVC-VMotion-2
Speriamo che con queste misure supplementari, si può facilmente prevenire i conflitti di indirizzi MAC durante l'esecuzione XVC-vMotions nell'ambiente vSphere, che può essere un dolore per risolvere i problemi.
Quando si cerca di sfruttare la nuova croce vCenter Server vMotion (XVC-vMotion) capacità di vSphere 6.0, sono MAC Address conflitti ancora una preoccupazione? Per rispondere a questa domanda, consente di dare un'occhiata a un esempio. Qui di seguito ho un grafico raffigurante due differenti distribuzioni vSphere 6.0. Il primo è composto da tre server vCenter che hanno aderito allo stesso dominio SSO chiamato vghetto.local e VM1 è attualmente gestito da VC1. Il secondo è un singolo server vCenter collegato ad una completamente diversa SSO Dominio chiamato vmware.local. Io anche assumere siamo messi bene Admin VI e abbiamo implementato ogni vCenter Server utilizzando un ID univoco (maggiori dettagli qui sul perché avere diverse questioni ID VC).
mac-address-XVC-VMotion-00
Consente di dire che siamo ora migrare VM1 da VC1 a VC2. Nelle versioni precedenti di vSphere, questo potenzialmente potrebbe portare a VC1 re-provisioning l'indirizzo MAC che VM1 è stato associato con perché Indirizzo MAC non era più gestito da VC1 e dal suo punto di vista, è ora disponibile. Anche se questo tipo di scenario è probabilmente rara nella maggior parte degli ambienti dei clienti, in un alto tasso di abbandono integrazione continua o ambiente erogazione continua, questo può essere un problema reale. Così è stato migliorato nulla in vSphere 6.0? La risposta è sì, ovviamente:)
In vSphere 6.0, vCenter Server ora mantiene un indirizzo Blacklist VM MAC che su un successo XVC-vMotion aggiornerà questa lista nera con gli indirizzi MAC associati al VM migrato. Questo assicura che il server di origine vCenter non si ri-provisioning questi indirizzi MAC per appena creato macchine virtuali e questi indirizzi MAC sono fondamentalmente "lista nera" di essere utilizzato di nuovo come mostrato nella figura seguente.
mac-address-XVC-VMotion-1
Se decidiamo di migrazione VM1 dal VC2 torna VC1, la lista nera viene aggiornata automaticamente e "lista nera" Indirizzi MAC verrà rimosso. Se decidiamo di migrare VM1 a un server completamente diverso vCenter che non fa parte dello stesso dominio SSO, l'indirizzo MAC potrebbe potenzialmente essere riutilizzato, ma dipenderà dal vostro ambiente se VC4 è su un segmento L2 completamente diverso, allora non si sarebbe verificato un conflitto Indirizzo MAC.
A partire da ora, non c'è modo automatico della bonifica lista nera indirizzi MAC, si tratta di un processo manuale che deve essere avviata attraverso una API vSphere privato. Spero che saremo in grado di ottenere questo documentato in un funzionario VMware KB, in modo che in caso questo è necessaria, si può facilmente seguire i semplici passaggi per eseguire le API necessarie. Recupero automatico è stato guardato da Engineering e speriamo di vedere questo in un futuro patch / aggiornamento in vSphere. Nel complesso, questo non dovrebbe in realtà dovrebbe essere una preoccupazione dato che vCenter Server può generare in modo univoco circa 65.000 unici indirizzi MAC e si dovrebbe fare un bel po 'XVC-vMotions prima mai dover recuperare dalla lista nera.
Una cosa da tenere presente quando si esegue XVC-vMotion o EXVC-vMotion è che attualmente non vi sono controlli pre-volo per MAC conflitti di indirizzo del server di destinazione vCenter (qualcosa di Ingegneria è alla ricerca di aggiornamento in un futuro patch / versione di aggiornamento). Detto questo, ci sono due ulteriori misure si possono attuare in voi ambiente per prevenire conflitti MAC Address:
Crea allarme vCenter Server in grado di rilevare e notificare un duplicato MAC Address in voi ambiente (applicabile anche a vSphere 5.5)
Controllare proattivamente per vedere se gli indirizzi MAC esistenti del vostro VM è attualmente in uso prima di eseguire un XVC-vMotion, questo è particolarmente utile quando si eseguono EXVC-vMotion .
Per aiutare con con il numero 2, ho creato un semplice script PowerCLI chiamato check-vm-mac-conflict.ps1 che accetta sia la sorgente e la destinazione vCenter Server, nonché il nome del VM nel VC di origine da migrare. Controllerà indirizzi MAC del VM nel VC destinazione e garantire che non vi siano conflitti. Se c'è un conflitto, il risultato sarà il nome della destinazione VM e l'indirizzo MAC che è in conflitto come si vede nello screenshot qui sotto.
mac-address-XVC-VMotion-2
Speriamo che con queste misure supplementari, si può facilmente prevenire i conflitti di indirizzi MAC durante l'esecuzione XVC-vMotions nell'ambiente vSphere, che può essere un dolore per risolvere i problemi.
lunedì 2 marzo 2015
Accesso al client vSphere Web da un desktop Linux?
A miss-comune concezione sul client vSphere Web è che non è accessibile da un desktop basato su Linux. Contrariamente alla credenza popolare, questo è in realtà possibile, almeno da un punto di vista tecnico, come accennato in questo VMware KB . Una recente discussione su questo argomento aveva suscitato il mio interesse come la mia comprensione se il vSphere Client Web potrebbe anche lavorare su un desktop Linux è confusa al meglio perché non è un sistema operativo desktop che uso regolarmente.
Anche se questo può ancora si presenta come una sorpresa per alcune persone, Adobe Flash è infatti un obbligo di utilizzare il client vSphere Web. In realtà ci sono due modi per soddisfare questo requisito con qualsiasi moderna distribuzione Linux desktop. Nell'esempio che segue, sto utilizzando l'ultima Ubuntu Desktop 14.04 distribuzione di dimostrare le due opzioni.
La prima opzione è la più "comoda", semplicemente utilizzando l'ultima versione del browser Google Chrome che in realtà raggruppa il Pepper Flash Plugin (maggiori dettagli possono essere trovati qui da Adobe). Ecco i comandi CLI per eseguire l'installazione di Google Chrome su Ubuntu, si acn facilmente fare una ricerca per le istruzioni per altre distribuzioni Linux.
sudo sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stabile principale" >> /etc/apt/sources.list.d/google.list'
wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
sudo apt-get update
sudo apt-get install -y google-chrome-stabile
Ecco uno screenshot utilizzando Google Chrome si collega ad un ambiente vSphere 6.0, nonché l'accesso al VMRC di una VM:
vSphere-web-client-linux-desktop-1
La seconda opzione è un po 'meno "conveniente" dal momento che è necessario installare il Pepper Flash Plugin, oltre al browser che supporta questo plugin che è Chromium. Ecco i comandi CLI per eseguire l'installazione di Chromium su Ubuntu, si può facilmente fare una ricerca on-line per le istruzioni per altre distribuzioni Linux.
sudo apt-get update
sudo apt-get -y install pepperflashplugin-nonfree
sudo apt-get -y install chromium-Browser
Ecco uno screenshot con Chromium connette a un vSphere 6.0 ambiente e sarà anche in grado di accedere al VMRC di una VM:
vSphere-web-client-linux-desktop-0
Questo sembra piuttosto buono giusto? Voglio dire, è possibile accedere all'interfaccia utente Web Client vSphere per eseguire le operazioni di base e accedere alla console VM utilizzando il VMRC basato HTML5. Beh, quasi, ma ci sono un paio di avvertimenti di essere a conoscenza che non può essere evidente in un primo momento. Oltre alle operazioni di base e l'accesso Controllo remoto macchina virtuale, c'è qualche altre funzionalità importanti vSphere Client Web offre oggi:
Distribuzione OVF / OVA
Autenticazione sessione di Windows
Caricamento di file su un vSphere datastore
ISO Montaggio / Immagine Floppy
Collegamento di dispositivi locali (ad esempio USB / CD-ROM)
Le funzionalità di cui sopra sono resi disponibili attraverso ciò che è noto come il client di integrazione plug-in (CIP), che è qualcosa che viene scaricato dal server vSphere client Web e installata localmente sul desktop. Un programma di installazione Linux CIP non è al momento disponibile oggi e la funzionalità di cui sopra non sarebbe disponibile nel client vSphere Web. Detto questo, non tutto è perduto e ci sono alcune soluzioni. Se si desidera distribuire un OVF / OVA, è comunque possibile installare OVFTool che è disponibile su Linux e invece di utilizzare l'interfaccia utente per guidare l'implementazione, può essere fatto attraverso la CLI. Per caricare file come un ISO, è possibile utilizzare l'API vSphere / CLI, come mostrato qui o SCP'ing direttamente all'host ESXi. Una volta che la ISO è caricato, è possibile montare al vostro VM dal vSphere Datastore.
Anche se questo è ben lungi dall'essere una soluzione perfetta per gli utenti desktop Linux-based, non permette di accedere alle funzionalità di gestione di base del client vSphere Web. C'è sicuramente spazio per migliorare, e questo è un settore che PM / Ingegneria sta cercando di migliorare ulteriormente in futuro. C'è stato anche un sacco di miglioramenti alle prestazioni e usabilità generali nel nuovo vSphere 6.0 client Web che beneficeranno tutte le piattaforme e, se siete interessati a saperne di più su quelli, controlla il post sul blog dal PM client vSphere Web qui .
Anche se questo può ancora si presenta come una sorpresa per alcune persone, Adobe Flash è infatti un obbligo di utilizzare il client vSphere Web. In realtà ci sono due modi per soddisfare questo requisito con qualsiasi moderna distribuzione Linux desktop. Nell'esempio che segue, sto utilizzando l'ultima Ubuntu Desktop 14.04 distribuzione di dimostrare le due opzioni.
La prima opzione è la più "comoda", semplicemente utilizzando l'ultima versione del browser Google Chrome che in realtà raggruppa il Pepper Flash Plugin (maggiori dettagli possono essere trovati qui da Adobe). Ecco i comandi CLI per eseguire l'installazione di Google Chrome su Ubuntu, si acn facilmente fare una ricerca per le istruzioni per altre distribuzioni Linux.
sudo sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stabile principale" >> /etc/apt/sources.list.d/google.list'
wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
sudo apt-get update
sudo apt-get install -y google-chrome-stabile
Ecco uno screenshot utilizzando Google Chrome si collega ad un ambiente vSphere 6.0, nonché l'accesso al VMRC di una VM:
vSphere-web-client-linux-desktop-1
La seconda opzione è un po 'meno "conveniente" dal momento che è necessario installare il Pepper Flash Plugin, oltre al browser che supporta questo plugin che è Chromium. Ecco i comandi CLI per eseguire l'installazione di Chromium su Ubuntu, si può facilmente fare una ricerca on-line per le istruzioni per altre distribuzioni Linux.
sudo apt-get update
sudo apt-get -y install pepperflashplugin-nonfree
sudo apt-get -y install chromium-Browser
Ecco uno screenshot con Chromium connette a un vSphere 6.0 ambiente e sarà anche in grado di accedere al VMRC di una VM:
vSphere-web-client-linux-desktop-0
Questo sembra piuttosto buono giusto? Voglio dire, è possibile accedere all'interfaccia utente Web Client vSphere per eseguire le operazioni di base e accedere alla console VM utilizzando il VMRC basato HTML5. Beh, quasi, ma ci sono un paio di avvertimenti di essere a conoscenza che non può essere evidente in un primo momento. Oltre alle operazioni di base e l'accesso Controllo remoto macchina virtuale, c'è qualche altre funzionalità importanti vSphere Client Web offre oggi:
Distribuzione OVF / OVA
Autenticazione sessione di Windows
Caricamento di file su un vSphere datastore
ISO Montaggio / Immagine Floppy
Collegamento di dispositivi locali (ad esempio USB / CD-ROM)
Le funzionalità di cui sopra sono resi disponibili attraverso ciò che è noto come il client di integrazione plug-in (CIP), che è qualcosa che viene scaricato dal server vSphere client Web e installata localmente sul desktop. Un programma di installazione Linux CIP non è al momento disponibile oggi e la funzionalità di cui sopra non sarebbe disponibile nel client vSphere Web. Detto questo, non tutto è perduto e ci sono alcune soluzioni. Se si desidera distribuire un OVF / OVA, è comunque possibile installare OVFTool che è disponibile su Linux e invece di utilizzare l'interfaccia utente per guidare l'implementazione, può essere fatto attraverso la CLI. Per caricare file come un ISO, è possibile utilizzare l'API vSphere / CLI, come mostrato qui o SCP'ing direttamente all'host ESXi. Una volta che la ISO è caricato, è possibile montare al vostro VM dal vSphere Datastore.
Anche se questo è ben lungi dall'essere una soluzione perfetta per gli utenti desktop Linux-based, non permette di accedere alle funzionalità di gestione di base del client vSphere Web. C'è sicuramente spazio per migliorare, e questo è un settore che PM / Ingegneria sta cercando di migliorare ulteriormente in futuro. C'è stato anche un sacco di miglioramenti alle prestazioni e usabilità generali nel nuovo vSphere 6.0 client Web che beneficeranno tutte le piattaforme e, se siete interessati a saperne di più su quelli, controlla il post sul blog dal PM client vSphere Web qui .
Iscriviti a:
Post (Atom)