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 .
venerdì 20 febbraio 2015
Lo sapevate che di una capacità aggiuntiva vMotion fresco in vSphere 6.0?
C'era un ottimo post di Duncan un paio di settimane fa andare oltre le nuove funzionalità vMotion in vSphere 6.0, che comprende: Croce vSwitch vMotion, Croce vCenter vMotion (XVC-vMotion) e Long Distance vMotion (LD-vMotion). Se non avete controllato il suo articolo, mi raccomando si dà una lettura prima di procedere ulteriormente. Dopo aver letto l'articolo di Duncan, ho notato che aveva perso su una capacità di vMotion supplementare che potrebbe non essere evidente come l'opzione non è dove si trovano nell'interfaccia utente vSphere client Web. In realtà, ero solo a conoscenza di questa capacità supplementare dopo aver sentito parlare da Ingegneria durante lo sviluppo di vSphere 6.
La capacità vMotion supplementare in realtà si estende il flusso di lavoro di Croce vCenter Server vMotion (XVC-vMotion), che consente a un amministratore di vivere migrare una macchina virtuale in esecuzione tra due server vCenter che fanno parte dello stesso dominio SSO. In virtù di essere nello stesso dominio SSO utilizzando la nuova funzione Modalità Linked avanzata, entrambi i server vCenter saranno visibili nel client vSphere Web e saranno disponibili per essere selezionata sia come origine o destinazione per un'operazione di vMotion.
Screen shot 2015/02/07 alle 10.34.53 AM
Questa capacità Croce vCenter Server vMotion esteso (ufficiosamente Chiedo che EXVC-vMotion) consente a un amministratore di vivere migrare una macchina virtuale in esecuzione tra due server vCenter che sono non parte dello stesso dominio SSO. Non è fantastico !? A mio parere, questo è in realtà un affare abbastanza grande, perché penso che toglie davvero alcun limite per una macchina virtuale vSphere e si aprirà un intero nuova classe di casi d'uso di mobilità che non sono mai pensato possibile prima. Questo sarà sicuramente renderlo interessante per i clienti che desiderano migrare i carichi di lavoro da loro on-premises datacenter in un ambiente vSphere completamente diverso o anche uno che è ospitato da un fornitore di servizi o forse anche vCloud Air?
L'operazione EXVC-vMotion è attualmente disponibile solo oggi utilizza l'API vSphere, non perché si tratta di una API private, ma perché non c'è wizard interfaccia utente per questa operazione. La ragione per l'attuale XVC-vMotion è così perfetta oggi è che sia il server di origine e di destinazione vCenter è visibile facendo parte dello stesso dominio SSO. Se avete due completamente diversi server vCenter che non sono uniti alla stessa SSO Dominio o hanno completamente diverso SSO Domini, allora è necessario utilizzare l'API vSphere per eseguire questa operazione.
Tutte le operazioni di vMotion compreso vMotion senza storage condiviso utilizza l'API vSphere RelocateVM_Task () metodo. In vSphere 6.0, il metodo è stato migliorato per accettare una nuova proprietà denominata ServiceLocator che fornisce un endpoint del servizio a un server vCenter in cui una macchina virtuale può essere migrato. Una cosa importante da notare è che se si desidera migrare una VM tra due server vCenter situate nello stesso dominio SSO, c'è un sslThumbprint proprietà che non è necessario per impostare. Tuttavia, se i due server vCenter non fanno parte dello stesso dominio SSO, quindi è necessario impostare la proprietà. Inoltre, se la VM è migrato a un diverso server vCenter, proprietà aggiuntive come l'host ESXi, vSphere Cluster / Pool di risorse e datastore devono essere specificati come parte della specifica migrazione.
Per dimostrare questo impressionante operazione EXVC-vMotion, ho creato un semplice script PowerCLI chiamato run-cool-EXVC-vMotion.ps1 che accetta 12 parametri della riga di comando che sono descritti in dettaglio più avanti:
Variabile Descrizione
sourceVC Il nome host o indirizzo IP del server di origine vCenter
sourceVCUsername Il nome utente per il collegamento alla sorgente vCenter Server
sourceVCPassword La password per il collegamento della sorgente vCenter Server
destVC Il nome host o indirizzo IP del server di destinazione vCenter
destVCUsername Il nome utente per la connessione al server di destinazione vCenter
destVCPassword La password per la connessione al server di destinazione vCenter
destVCThumbprint L'identificazione SSL (SHA1) del server di destinazione vCenter (può essere recuperato utilizzando questo o questo )
DataStoreName La destinazione vSphere Datastore dove verrà migrato il VM
clustername La destinazione vSphere Cluster dove verrà migrato il VM
vmhostname La destinazione vSphere ESXi host su cui verrà migrato il VM
vmnetworkname La destinazione vSphere VM Portgroup dove verrà migrato il VM
nomevm Il nome della VM di origine da migrare
Nel mio ambiente di laboratorio, ho configurato due vCenter Server di cui fanno parte di due diversi SSO domini come si vede nello screenshot qui sotto:
Screen shot 2015/02/10 alle 5.53.47 AM
Ho minuscolo Linux VM (VMA) che sto usando che sarò Migrazione da vcenter60-4 a vcenter60-5 che ha un datastore completamente diverso e VM portgroup (se si è allungato / esteso L2, quindi la VM sarebbe rimasto in linea durante questa migrazione). Ho poi eseguire lo script utilizzando i seguenti parametri in base alla mia proprio ambiente e si può vedere la migrazione è dando il via:
. \ Run-cool-EXVC-vMotion.ps1 vcenter60-4.primp-industries.com administrator@vghetto.local VMware1! vcenter60-5.primp-industries.com administrator@vsphere.local VMware1! 82: D0: CF: B5: CC: EA: FE: AE: 03: BE: E9: 4B: AC: A2: B0: AB: 2F: E3: 87: 49 vesxi60-8-local-storage NY-Cluster vesxi60 -8.primp-industries.com NY-VM-Network VMA
Screen shot 2015/02/10 alle 6.05.46 AM
Uno la migrazione è stata completata, se oggi diamo uno sguardo al nostro Web client vSphere, possiamo vedere la VM è ora migrato verso l'altro server vCenter.
Screen shot 2015/02/10 alle 5.57.01 AM
Spero davvero di vedere la vSphere Client Web ottenere migliorato per supportare questa funzionalità vMotion fresco, ma nel frattempo si può facilmente eseguire questa operazione utilizzando lo script PowerCLI sopra o qualsiasi altro linguaggio di scripting / programmazione rimettere in API vSphere. Imposta il tuo VM gratis e lasciarlo migrare dove il tuo cuore desidera:)
La capacità vMotion supplementare in realtà si estende il flusso di lavoro di Croce vCenter Server vMotion (XVC-vMotion), che consente a un amministratore di vivere migrare una macchina virtuale in esecuzione tra due server vCenter che fanno parte dello stesso dominio SSO. In virtù di essere nello stesso dominio SSO utilizzando la nuova funzione Modalità Linked avanzata, entrambi i server vCenter saranno visibili nel client vSphere Web e saranno disponibili per essere selezionata sia come origine o destinazione per un'operazione di vMotion.
Screen shot 2015/02/07 alle 10.34.53 AM
Questa capacità Croce vCenter Server vMotion esteso (ufficiosamente Chiedo che EXVC-vMotion) consente a un amministratore di vivere migrare una macchina virtuale in esecuzione tra due server vCenter che sono non parte dello stesso dominio SSO. Non è fantastico !? A mio parere, questo è in realtà un affare abbastanza grande, perché penso che toglie davvero alcun limite per una macchina virtuale vSphere e si aprirà un intero nuova classe di casi d'uso di mobilità che non sono mai pensato possibile prima. Questo sarà sicuramente renderlo interessante per i clienti che desiderano migrare i carichi di lavoro da loro on-premises datacenter in un ambiente vSphere completamente diverso o anche uno che è ospitato da un fornitore di servizi o forse anche vCloud Air?
L'operazione EXVC-vMotion è attualmente disponibile solo oggi utilizza l'API vSphere, non perché si tratta di una API private, ma perché non c'è wizard interfaccia utente per questa operazione. La ragione per l'attuale XVC-vMotion è così perfetta oggi è che sia il server di origine e di destinazione vCenter è visibile facendo parte dello stesso dominio SSO. Se avete due completamente diversi server vCenter che non sono uniti alla stessa SSO Dominio o hanno completamente diverso SSO Domini, allora è necessario utilizzare l'API vSphere per eseguire questa operazione.
Tutte le operazioni di vMotion compreso vMotion senza storage condiviso utilizza l'API vSphere RelocateVM_Task () metodo. In vSphere 6.0, il metodo è stato migliorato per accettare una nuova proprietà denominata ServiceLocator che fornisce un endpoint del servizio a un server vCenter in cui una macchina virtuale può essere migrato. Una cosa importante da notare è che se si desidera migrare una VM tra due server vCenter situate nello stesso dominio SSO, c'è un sslThumbprint proprietà che non è necessario per impostare. Tuttavia, se i due server vCenter non fanno parte dello stesso dominio SSO, quindi è necessario impostare la proprietà. Inoltre, se la VM è migrato a un diverso server vCenter, proprietà aggiuntive come l'host ESXi, vSphere Cluster / Pool di risorse e datastore devono essere specificati come parte della specifica migrazione.
Per dimostrare questo impressionante operazione EXVC-vMotion, ho creato un semplice script PowerCLI chiamato run-cool-EXVC-vMotion.ps1 che accetta 12 parametri della riga di comando che sono descritti in dettaglio più avanti:
Variabile Descrizione
sourceVC Il nome host o indirizzo IP del server di origine vCenter
sourceVCUsername Il nome utente per il collegamento alla sorgente vCenter Server
sourceVCPassword La password per il collegamento della sorgente vCenter Server
destVC Il nome host o indirizzo IP del server di destinazione vCenter
destVCUsername Il nome utente per la connessione al server di destinazione vCenter
destVCPassword La password per la connessione al server di destinazione vCenter
destVCThumbprint L'identificazione SSL (SHA1) del server di destinazione vCenter (può essere recuperato utilizzando questo o questo )
DataStoreName La destinazione vSphere Datastore dove verrà migrato il VM
clustername La destinazione vSphere Cluster dove verrà migrato il VM
vmhostname La destinazione vSphere ESXi host su cui verrà migrato il VM
vmnetworkname La destinazione vSphere VM Portgroup dove verrà migrato il VM
nomevm Il nome della VM di origine da migrare
Nel mio ambiente di laboratorio, ho configurato due vCenter Server di cui fanno parte di due diversi SSO domini come si vede nello screenshot qui sotto:
Screen shot 2015/02/10 alle 5.53.47 AM
Ho minuscolo Linux VM (VMA) che sto usando che sarò Migrazione da vcenter60-4 a vcenter60-5 che ha un datastore completamente diverso e VM portgroup (se si è allungato / esteso L2, quindi la VM sarebbe rimasto in linea durante questa migrazione). Ho poi eseguire lo script utilizzando i seguenti parametri in base alla mia proprio ambiente e si può vedere la migrazione è dando il via:
. \ Run-cool-EXVC-vMotion.ps1 vcenter60-4.primp-industries.com administrator@vghetto.local VMware1! vcenter60-5.primp-industries.com administrator@vsphere.local VMware1! 82: D0: CF: B5: CC: EA: FE: AE: 03: BE: E9: 4B: AC: A2: B0: AB: 2F: E3: 87: 49 vesxi60-8-local-storage NY-Cluster vesxi60 -8.primp-industries.com NY-VM-Network VMA
Screen shot 2015/02/10 alle 6.05.46 AM
Uno la migrazione è stata completata, se oggi diamo uno sguardo al nostro Web client vSphere, possiamo vedere la VM è ora migrato verso l'altro server vCenter.
Screen shot 2015/02/10 alle 5.57.01 AM
Spero davvero di vedere la vSphere Client Web ottenere migliorato per supportare questa funzionalità vMotion fresco, ma nel frattempo si può facilmente eseguire questa operazione utilizzando lo script PowerCLI sopra o qualsiasi altro linguaggio di scripting / programmazione rimettere in API vSphere. Imposta il tuo VM gratis e lasciarlo migrare dove il tuo cuore desidera:)
giovedì 5 febbraio 2015
Handy nuove API vSphere 6.0 di essere a conoscenza di
Il numero di nuove funzionalità della piattaforma e funzionalità di vSphere 6.0 è di gran lunga il più grande che abbia mai visto in un po '. Una delle cose che mi piace fare con ogni nuova versione vSphere è rivedere tutte le nuove API che sono ora disponibili per essere consumato. Ecco alcune delle nuove API vSphere che ritengo interessante dal punto di vista di automazione per vSphere 6 che credo la gente dovrebbe essere a conoscenza. So che per me, ci sono diverse nuove API vSphere che ho personalmente aspettato per un bel po 'di tempo e sono felice di vedere finalmente a disposizione per i nostri clienti, sviluppatori e partner. A seconda del mio tempo libero, posso andare in maggiori dettagli su come alcune di queste nuove API di lavoro e fornire alcuni codici di esempio.
Se volete vedere l'elenco completo delle nuove API vSphere 6.0, assicurati di controllare le API Reference Guide vSphere 6.0 (disponibile quando vSphere 6.0 di GA che è Q1 del 2015), che ha un "Novità" a tutti i nuovi Managed Objects, metodi, proprietà, ecc
CertificateManager - API per implementare e aggiornare Vmca (VMware Certificate Authority) certificati SSL per gli host ESXi
- CertMgrRefreshCACertificatesAndCRLs_Task
- CertMgrRefreshCertificates_Task
- CertMgrRevokeCertificates_Task
ClusterEVCManager - API per gestire finalmente e configurare EVC (Enhanced vMotion compatibilità) per un cluster vSphere
- CheckAddHostEvc_Task
- CheckConfigureEvcMode_Task
- ConfigureEvcMode_Task
- DisableEvcMode_Task
IoFilterManager - API per gestire la nuova funzionalità Filtro IO
- InstallIoFilter_Task
- QueryDisksUsingFilter
- QueryIoFilterInfo
- QueryIoFilterIssues
- ResolveInstallationErrorsOnCluster_Task
- ResolveInstallationErrorsOnHost_Task
- UninstallIoFilter_Task
- UpgradeIoFilter_Task
ClusterComputeResource - API ad occhiata rapidamente tutte le regole di affinità e anti-affinità per un VM
- FindRulesForVm
VSAN API 6.0 / VVOL / NFS v4.1 - Si prega di dare un'occhiata qui
HostStorageSystem
- Contrassegno di un dispositivo Disk come locale o remoto
- MarkAsLocal_Task
- MarkAsNonLocal_Task
- Contrassegno di un dispositivo Disk sia come SSD o disco magnetico
- MarkAsNonSsd_Task
- MarkAsSsd_Task
- Accendere di spegnimento del dispositivo Disk LED supportato
- TurnDiskLocatorLedOn_Task
- TurnDiskLocatorLedOff_Task
- Operazione VMFS unmap
- UnmapVmfsVolumeEx_Task
HostCertificateManager - API per gestire e aggiornare personalizzato CA firmato certificati SSL su host ESXi
- GenerateCertificateSigningRequest
- GenerateCertificateSigningRequestByDn
- InstallServerCertificate
- ListCACertificateRevocationLists
- ListCACertificates
- ReplaceCACertificatesAndCRLs
HostActiveDirectoryAuthentication - API per gestire autenticazione con smart card su host ESXi
- DisableSmartCardAuthentication
- EnableSmartCardAuthentication
- InstallSmartCardTrustAnchor
- ListSmartCardTrustAnchors
- RemoveSmartCardTrustAnchor
- RemoveSmartCardTrustAnchorByFingerprint
- ReplaceSmartCardTrustAnchors
HostAccessManager - API per la gestione di nuove funzionalità di modalità di blocco e modificare gli utenti del sistema
- ChangeAccessMode
- ChangeLockdownMode
- QueryLockdownExceptions
- QuerySystemUsers
- RetrieveHostAccessControlEntries
- UpdateLockdownExceptions
- UpdateSystemUsers
VirtualMachine
- Abilita SMP-FT per VM
- CreateSecondaryVMEx_Task
- Invia NMI (Non-Masking Interrupt) richiesta di VM
- SendNMI
GuestWindowsRegistryManager - API per gestire le chiavi di registro di Windows per sistemi operativi guest
- CreateRegistryKeyInGuest
- DeleteRegistryKeyInGuest
- DeleteRegistryValueInGuest
- ListRegistryKeysInGuest
- ListRegistryValuesInGuest
- SetRegistryValueInGuest
lunedì 26 gennaio 2015
hunderbolt archiviazione per ESXi
Una domanda che ho spesso ricevo è se ESXi supporta dispositivi di storage basati su Thunderbolt. Questo è particolarmente interessante per le persone in esecuzione ESXi su un Apple Mac Mini a causa del numero limitato di connessioni IO Mac Mini 'hanno. Se si guarda in HCL di VMware, non troverete alcun dispositivo Thunderbolt storage supportati Né vi sono che sono in fase di test attivamente con ESXi, almeno per quanto ne so.
Detto questo, in generale da un punto di vista host ESXi, l'interfaccia Thunderbolt è solo visto come un bus PCIe esteso. Ciò significa che qualsiasi dispositivo di memorizzazione è collegato all'altra estremità può funzionare con ESXi finché c'è un conducente ESXi che può comunicare con dispositivi che. Questo è analogo ad avere una scheda RAID e avente i driver corretti sul ESXi vedere il suo stoccaggio.
Anche se VMware non sta testando attivamente dispositivi di storage basati su Thunderbolt, ci sono un paio di persone nella comunità che hanno e hanno avuto successo. Volevo condividere queste storie con la comunità di coloro che potrebbero essere interessati a questo argomento e, auspicabilmente, altri che hanno avuto un successo simile può anche condividere maggiori dettagli circa la loro messa a punto.
Disclaimer: Tutte le soluzioni elencate di seguito sono da parte della comunità e le decisioni di acquisto sulla base di queste soluzioni sarà a vostro rischio e pericolo. Tengo alcuna responsabilità se le soluzioni elencate non funzionano per qualsiasi ragione.
Soluzione # 1 - Pegaus R6 Thunderbolt Storage Enclosure
Questo è stato il primo dispositivo di storage Thunderbolt che non avevo mai visto confermato pubblicamente di lavorare con ESXi dopo l'installazione di un driver STEX VIB. Potete trovare maggiori dettagli qui .
Soluzione # 2 - Sonnet Echo espresso III-R Rackmount Thunderbolt 2 Expansion Chassis & RacMac Mini Enclosure
Questa soluzione successiva è stato recentemente condiviso con me da Marc Huppert che ha recentemente ampliato il suo laboratorio a casa. Marc combinato un chassis di espansione Thunderbolt con un Mac Mini telaio a vista storage Fibre Channel al suo Mac Mini. Potete trovare maggiori dettagli qui .
Soluzione # 3 - XMAC Mini Server Enclosure
Mi sono imbattuto in questa soluzione durante la ricerca on-line che usa anche un altro chassis di espansione Mac Mini Thunderbolt collegati allo storage basato Fibre Channel. Potete trovare maggiori dettagli qui .
Soluzione # 4 - Sonnet XMAC Pro Enclosure Server
Grazie a Joshua per condividere la sua soluzione. Potete trovare maggiori dettagli nei commenti qui .
Soluzione # 5 - unità LaCie Rugged Thunderbolt
Grazie a Filippo per condividere la sua soluzione. Potete trovare maggiori dettagli nei commenti qui .
Soluzione # 6 - ARC-8050T2 Thunderbolt 2 RAID
Grazie a Jason per condividere la sua soluzione. Potete trovare maggiori dettagli nei commenti qui .
Se ci sono altre periferiche di archiviazione di Thunderbolt che voi o gli altri hanno avuto successo con ESXi, sentitevi liberi di lasciare un commento con i dettagli e lo aggiungerò al post. Se ci sono fornitori di dispositivi di storage Thunderbolt che vogliono mandarmi una unità demo, sarei più che felice di dare al sistema un test per vedere se funziona con ESXi:)
Detto questo, in generale da un punto di vista host ESXi, l'interfaccia Thunderbolt è solo visto come un bus PCIe esteso. Ciò significa che qualsiasi dispositivo di memorizzazione è collegato all'altra estremità può funzionare con ESXi finché c'è un conducente ESXi che può comunicare con dispositivi che. Questo è analogo ad avere una scheda RAID e avente i driver corretti sul ESXi vedere il suo stoccaggio.
Anche se VMware non sta testando attivamente dispositivi di storage basati su Thunderbolt, ci sono un paio di persone nella comunità che hanno e hanno avuto successo. Volevo condividere queste storie con la comunità di coloro che potrebbero essere interessati a questo argomento e, auspicabilmente, altri che hanno avuto un successo simile può anche condividere maggiori dettagli circa la loro messa a punto.
Disclaimer: Tutte le soluzioni elencate di seguito sono da parte della comunità e le decisioni di acquisto sulla base di queste soluzioni sarà a vostro rischio e pericolo. Tengo alcuna responsabilità se le soluzioni elencate non funzionano per qualsiasi ragione.
Soluzione # 1 - Pegaus R6 Thunderbolt Storage Enclosure
Questo è stato il primo dispositivo di storage Thunderbolt che non avevo mai visto confermato pubblicamente di lavorare con ESXi dopo l'installazione di un driver STEX VIB. Potete trovare maggiori dettagli qui .
Soluzione # 2 - Sonnet Echo espresso III-R Rackmount Thunderbolt 2 Expansion Chassis & RacMac Mini Enclosure
Questa soluzione successiva è stato recentemente condiviso con me da Marc Huppert che ha recentemente ampliato il suo laboratorio a casa. Marc combinato un chassis di espansione Thunderbolt con un Mac Mini telaio a vista storage Fibre Channel al suo Mac Mini. Potete trovare maggiori dettagli qui .
Soluzione # 3 - XMAC Mini Server Enclosure
Mi sono imbattuto in questa soluzione durante la ricerca on-line che usa anche un altro chassis di espansione Mac Mini Thunderbolt collegati allo storage basato Fibre Channel. Potete trovare maggiori dettagli qui .
Soluzione # 4 - Sonnet XMAC Pro Enclosure Server
Grazie a Joshua per condividere la sua soluzione. Potete trovare maggiori dettagli nei commenti qui .
Soluzione # 5 - unità LaCie Rugged Thunderbolt
Grazie a Filippo per condividere la sua soluzione. Potete trovare maggiori dettagli nei commenti qui .
Soluzione # 6 - ARC-8050T2 Thunderbolt 2 RAID
Grazie a Jason per condividere la sua soluzione. Potete trovare maggiori dettagli nei commenti qui .
Se ci sono altre periferiche di archiviazione di Thunderbolt che voi o gli altri hanno avuto successo con ESXi, sentitevi liberi di lasciare un commento con i dettagli e lo aggiungerò al post. Se ci sono fornitori di dispositivi di storage Thunderbolt che vogliono mandarmi una unità demo, sarei più che felice di dare al sistema un test per vedere se funziona con ESXi:)
giovedì 22 gennaio 2015
Cisco ACI - Configurazione VMware integrazione sul APIC
n questo articolo l'autore esamina il collegamento ad un sistema di gestione della macchina virtuale.
Nel precedente articolo ho scritto su Cisco ACI ho fatto riferimento alla guida Quickstart trovato nella APIC sotto Sistema >> Quickstart. Ho scritto il secondo passo, la configurazione di account utente. Ho anche scritto un articolo sulla creazione di costrutti di rete di base, come ad esempio gli inquilini e domini ponte. In questo articolo ho intenzione di continuare con il terzo passo nella guida di avvio rapido che è "Connessione a una macchina virtuale sistema di gestione (VM)." Questo articolo sarà esclusivamente concentrarsi sulla VMware per la maggior parte come questo è ciò che è disponibile con la versione GA di ACI come della scrittura di questo articolo. Integrazione Hyper-V sarà disponibile a breve. Stiamo anche usando il VMware vCenter per fare la maggior parte di questa configurazione.A partire da ora, ACI è compatibile solo con le versioni di vSphere 5.1 e 5.5, e probabilmente vSphere 6 quando non sarà rilasciato. Come nota a margine, l'APIC può anche usare vShield per l'integrazione con ACI, ma saremo a parlare di che in un prossimo articolo.
Possiamo usare VMware e altre piattaforme virtuali o fisici con ACI, anche se non abbiamo una soluzione come vCenter per collegarli. Sarebbe solo essere più di un processo manuale. Tuttavia quando integriamo vCenter e ACI siamo in grado di automatizzare i processi di creazione di gruppi di porte virtuali, per esempio, che ci permette anche di gestire le policy di rete di VMware attraverso l'APIC. Ovviamente, poiché una ragione principale per utilizzare ACI è di sfruttare programmabilità e automazione, questa è una buona cosa.
Come indicato nella Guida rapida per la connessione a un sistema di gestione VM dobbiamo avere connettività a una rete esterna utilizzando la rete di gestione in banda, prima creiamo un dominio VMM profilo. Un dominio Virtual Machine Manager è un gruppo di controller virtuali (come vCenter) con politiche simili associati. Quindi, andiamo avanti e creare che la connettività di livello 2 se non abbiamo già. Sto assumendo il tessuto e tutte le altre cose sono stati impostati in questo punto. Si prega di vedere i miei precedenti articoli o la documentazione di Cisco per aiutare con questo.
Breve Promemoria:
Figura 1
Figura 2
Come si può vedere in questo esempio ho un vCenter con il nome di VCVA e il suo stato è in linea. Il suo indirizzo è 198.18.133.211 ed è VMware vCenter Server 5.5.0 accumulo 1.312.298. Mi dà anche un numero di serie e mi dice quante distribuito switch virtuali sto controllano dal APIC. Sotto hypervisor mostra due server ESX, che è quello che sto correndo nella mia particolare laboratorio in questo caso.
Possiamo anche verificare la connessione sul lato VMware, e dovremmo verificare che tutto funzioni correttamente.Quindi cerchiamo di accedere nuovamente al client vSphere.
Figura 3
Ora che abbiamo creato il collegamento tra l'APIC e vCenter siamo in grado di automatizzare alcune cose come l'aggiunta di reti e VLAN per vCenter. Saremo in grado di aggiungere i nostri ospiti VMware per queste reti e che useremo il tessuto ACI di comunicare a quel punto. Tutto quello che realmente abbiamo lasciato è quello di aggiungere gli host ESX allo switch virtuale distribuito e quindi creare gruppi e reti per mettere le macchine virtuali, ma salveremo che per il prossimo blog della serie.
Come sempre, se avete domande o commenti, non esitate a lasciare i vostri commenti qui sotto o entrare in contatto con me su TwitterMalhoit.
Possiamo usare VMware e altre piattaforme virtuali o fisici con ACI, anche se non abbiamo una soluzione come vCenter per collegarli. Sarebbe solo essere più di un processo manuale. Tuttavia quando integriamo vCenter e ACI siamo in grado di automatizzare i processi di creazione di gruppi di porte virtuali, per esempio, che ci permette anche di gestire le policy di rete di VMware attraverso l'APIC. Ovviamente, poiché una ragione principale per utilizzare ACI è di sfruttare programmabilità e automazione, questa è una buona cosa.
Come indicato nella Guida rapida per la connessione a un sistema di gestione VM dobbiamo avere connettività a una rete esterna utilizzando la rete di gestione in banda, prima creiamo un dominio VMM profilo. Un dominio Virtual Machine Manager è un gruppo di controller virtuali (come vCenter) con politiche simili associati. Quindi, andiamo avanti e creare che la connettività di livello 2 se non abbiamo già. Sto assumendo il tessuto e tutte le altre cose sono stati impostati in questo punto. Si prega di vedere i miei precedenti articoli o la documentazione di Cisco per aiutare con questo.
Breve Promemoria:
- Clicca su inquilini, e quindi fare clic su Gestione. (Ricordate MGMT un inquilino di default)
- Nel riquadro di navigazione a sinistra espandere Networking
- Fare clic destro sul ponte Domini e cliccare su Crea Ponte Domini
- Dategli un nome e di rete.
- Fare clic sul + accanto a sottoreti e inserire la subnet che si desidera in modo da utilizzare
- Nel APIC GUI click su VM rete e selezionare i criteri sub-tab.
- Nel riquadro di navigazione a sinistra selezionare VM Provider VMware.
- Cliccate sulle azioni e quindi Create vCenter dominio. Un dominio è come Cisco si riferisce a qualsiasi connessione virtuale, se si tratta di Hyper-V, Xen o VMware.
- Compilare il nome del vCenter e accertarsi che corrisponda al nome del vCenter. In questo caso ho intenzione di utilizzare My-vCenter.
- Accanto a VLAN Pool selezionare la freccia a discesa e selezionare Create VLAN Pool. Queste saranno le piscine che vengono creati sul Virtual Switch Distributed entro vCenter.
- Dare la piscina un nome come Production_VLAN_Pool e lasciare allocazione dinamica selezionato. In questo modo la creazione della piscina sul vCenter essere automatizzato.
- Quindi fare clic sul segno + accanto ai blocchi ENCAP. Aggiungi la tua gamma VLAN qui e fare clic su Submit (Se siete abituati a creare piscine in UCS, questo è un po 'come questo, stiamo riservando piscine per uso successivo).
- Fare clic sul segno + accanto a credenziali vCenter per aggiungere le credenziali appropriate per la connessione a vCenter.
Figura 1
- Fare clic sul segno + accanto a vCenter / vShield. Anche in questo caso, non stiamo utilizzando vShield in questo caso, ma qui ci inserire le informazioni di connessione vCenter.
- Dategli un nome per abbinare il vostro vCenter.
- Specificare l'indirizzo IP corretto per vCenter.
- È possibile lasciare la versione DVS in default.
- Inserire le informazioni Datacenter.
- Scegliere la credenziale associata, che abbiamo creato prima di questo. In questo caso si tratta di amministratore.
- Infine, fare clic presentare per terminare la creazione della VM Provider.
Figura 2
Come si può vedere in questo esempio ho un vCenter con il nome di VCVA e il suo stato è in linea. Il suo indirizzo è 198.18.133.211 ed è VMware vCenter Server 5.5.0 accumulo 1.312.298. Mi dà anche un numero di serie e mi dice quante distribuito switch virtuali sto controllano dal APIC. Sotto hypervisor mostra due server ESX, che è quello che sto correndo nella mia particolare laboratorio in questo caso.
Possiamo anche verificare la connessione sul lato VMware, e dovremmo verificare che tutto funzioni correttamente.Quindi cerchiamo di accedere nuovamente al client vSphere.
- Accedere a vSphere client.
- Fare clic sul menu a top menu a discesa accanto a inventario dove si dice Host e cluster e modificarlo in rete.
- Espandere la cartella vCenter per mostrare uno switch virtuale distribuito, nel mio caso la sua chiamata VCVA.Questo è stato creato automaticamente quando abbiamo creato la connessione sul APIC.
Figura 3
Ora che abbiamo creato il collegamento tra l'APIC e vCenter siamo in grado di automatizzare alcune cose come l'aggiunta di reti e VLAN per vCenter. Saremo in grado di aggiungere i nostri ospiti VMware per queste reti e che useremo il tessuto ACI di comunicare a quel punto. Tutto quello che realmente abbiamo lasciato è quello di aggiungere gli host ESX allo switch virtuale distribuito e quindi creare gruppi e reti per mettere le macchine virtuali, ma salveremo che per il prossimo blog della serie.
Come sempre, se avete domande o commenti, non esitate a lasciare i vostri commenti qui sotto o entrare in contatto con me su TwitterMalhoit.
giovedì 15 gennaio 2015
Attributi personalizzati! = VSphere Tags
Una domanda comune che vedo frequenti poste dai clienti è se Attributi personalizzati in vCenter Server può essere completamente sostituita da vSphere Tags? Attributi Sia personalizzati e vSphere Tags fornire funzionalità di metadati, ma ci sono alcune differenze di fondo tra i due e, a seconda di come si utilizza Attributi personalizzati oggi, si può o non può essere in grado di migrare completamente verso utilizzando vSphere Tags, almeno nel breve termine.
Gli attributi personalizzati consente di specificare "chiavi" personalizzati associati sia con una macchina virtuale o un oggetto host ESXi, che sono gli oggetti solo supportati. Una volta abilitato sia per una VM o un host ESXi, si sarà in grado di assegnare un metadati specifici oggetto "valore" per questi oggetti. Un esempio potrebbe essere un attributo personalizzato denominato "proprietario dell'applicazione" e per VM1 ho un valore di "Duncan Epping" e per VM2 ho un valore di "Alan Renouf".
vSphere-custom-attributi-sono-non-uguali a vSphere-tags-1
vSphere Tags fornisce anche una capacità di metadati, ma va oltre la semplice VM e ESXi host. vSphere Tag può essere applicato a tutti gli oggetti all'interno del vSphere inventario. Un importante distinzione tra Attributi personalizzati e vSphere Tag che aiuteranno a rispondere alla nostra domanda iniziale è che vSphere Tag non può essere utilizzato per memorizzare i metadati specifici oggetto , viene utilizzato per categorizzare o logicamente l'organizzazione di vari oggetti insieme. Un esempio potrebbe essere un tag denominato "Production", che può quindi essere assegnato a VM1 e VM2 a fini organizzativi, ma non sarebbe in grado di assegnare un valore specifico per ciascuna delle macchine virtuali.
vSphere-custom-attributi-sono-non-uguali a vSphere-tags-0
Questa distinzione di non essere in grado di assegnare metadati specifici oggetto è la differenza fondamentale tra vSphere Tag e attributi personalizzati. Se attualmente affidamento su questa capacità di attributi personalizzati, non sarà in grado di migrare completamente verso utilizzando vSphere Tag. Un buon modo per pensare a vSphere Tags oggi è che sono simili a cartelle vSphere, ma molto più dinamico e di ricerca in tutti i vSphere Objects. La mancanza di metadati specifici oggetto per vSphere Tags è qualcosa che VMware Engineering è a conoscenza di oggi e speriamo che saranno in grado di migliorare in futuro per supportare gli attributi personalizzati caso d'uso, in modo che vSphere Tag può essere utilizzato esclusivamente.
In realtà, spero anche di vedere vSphere Tags ottenere migliorato in modo che le autorizzazioni possono essere applicati anche su Tag che sarebbe poi propagarsi alle vSphere sottostanti Oggetti associati. So che questo è un altro richiesta comune da parte dei clienti che hanno guardato con vSphere Tags. Mi piacerebbe vedere anche un adeguato API esposta per Tags in modo che possano essere gestiti e accessibili a livello di codice, che può essere molto utile per CMDB o sistemi di provisioning. Oggi, non ci sono le API vSphere per tag, ma è possibile gestire utilizzando cmdlet PowerCLI Tagging . Ricercabilità è anche un'altra area che vSphere Tags può ottenere ulteriori miglioramenti su. Oggi è possibile cercare solo su oggetti per nome Tag, ma in futuro spero di vedere il supporto per le query più complesse, che includono la ricerca attraverso i valori delle variabili assegnate.
In sintesi, gli attributi personalizzati non stanno andando via in qualunque momento presto, almeno fino a quando le loro capacità sono in pari con vSphere Tags. Sarete in grado di continuare ad accedere Attributi personalizzati che è disponibile oggi nel client vSphere # C o utilizzando l'API vSphere. Gli attributi personalizzati non sono attualmente visibili nel vSphere client Web, ma è possibile utilizzare questo plugin di vSphere Client Web personalizzata che rende disponibile Attributi personalizzati nel client vSphere Web. Andando avanti, il futuro sarà vSphere Tags, ma nel frattempo si consiglia di utilizzare entrambi i set di funzionalità di metadati a seconda del caso d'uso.
Gli attributi personalizzati consente di specificare "chiavi" personalizzati associati sia con una macchina virtuale o un oggetto host ESXi, che sono gli oggetti solo supportati. Una volta abilitato sia per una VM o un host ESXi, si sarà in grado di assegnare un metadati specifici oggetto "valore" per questi oggetti. Un esempio potrebbe essere un attributo personalizzato denominato "proprietario dell'applicazione" e per VM1 ho un valore di "Duncan Epping" e per VM2 ho un valore di "Alan Renouf".
vSphere-custom-attributi-sono-non-uguali a vSphere-tags-1
vSphere Tags fornisce anche una capacità di metadati, ma va oltre la semplice VM e ESXi host. vSphere Tag può essere applicato a tutti gli oggetti all'interno del vSphere inventario. Un importante distinzione tra Attributi personalizzati e vSphere Tag che aiuteranno a rispondere alla nostra domanda iniziale è che vSphere Tag non può essere utilizzato per memorizzare i metadati specifici oggetto , viene utilizzato per categorizzare o logicamente l'organizzazione di vari oggetti insieme. Un esempio potrebbe essere un tag denominato "Production", che può quindi essere assegnato a VM1 e VM2 a fini organizzativi, ma non sarebbe in grado di assegnare un valore specifico per ciascuna delle macchine virtuali.
vSphere-custom-attributi-sono-non-uguali a vSphere-tags-0
Questa distinzione di non essere in grado di assegnare metadati specifici oggetto è la differenza fondamentale tra vSphere Tag e attributi personalizzati. Se attualmente affidamento su questa capacità di attributi personalizzati, non sarà in grado di migrare completamente verso utilizzando vSphere Tag. Un buon modo per pensare a vSphere Tags oggi è che sono simili a cartelle vSphere, ma molto più dinamico e di ricerca in tutti i vSphere Objects. La mancanza di metadati specifici oggetto per vSphere Tags è qualcosa che VMware Engineering è a conoscenza di oggi e speriamo che saranno in grado di migliorare in futuro per supportare gli attributi personalizzati caso d'uso, in modo che vSphere Tag può essere utilizzato esclusivamente.
In realtà, spero anche di vedere vSphere Tags ottenere migliorato in modo che le autorizzazioni possono essere applicati anche su Tag che sarebbe poi propagarsi alle vSphere sottostanti Oggetti associati. So che questo è un altro richiesta comune da parte dei clienti che hanno guardato con vSphere Tags. Mi piacerebbe vedere anche un adeguato API esposta per Tags in modo che possano essere gestiti e accessibili a livello di codice, che può essere molto utile per CMDB o sistemi di provisioning. Oggi, non ci sono le API vSphere per tag, ma è possibile gestire utilizzando cmdlet PowerCLI Tagging . Ricercabilità è anche un'altra area che vSphere Tags può ottenere ulteriori miglioramenti su. Oggi è possibile cercare solo su oggetti per nome Tag, ma in futuro spero di vedere il supporto per le query più complesse, che includono la ricerca attraverso i valori delle variabili assegnate.
In sintesi, gli attributi personalizzati non stanno andando via in qualunque momento presto, almeno fino a quando le loro capacità sono in pari con vSphere Tags. Sarete in grado di continuare ad accedere Attributi personalizzati che è disponibile oggi nel client vSphere # C o utilizzando l'API vSphere. Gli attributi personalizzati non sono attualmente visibili nel vSphere client Web, ma è possibile utilizzare questo plugin di vSphere Client Web personalizzata che rende disponibile Attributi personalizzati nel client vSphere Web. Andando avanti, il futuro sarà vSphere Tags, ma nel frattempo si consiglia di utilizzare entrambi i set di funzionalità di metadati a seconda del caso d'uso.
venerdì 9 gennaio 2015
CoreOS è ora disponibile come OVA in canale alfa
Sembra che la gente oltre a CoreOS ora hanno anche prodotto una immagine OVA che può essere facilmente importato in un vSphere o anche ambiente vCloud Air. In precedenza, ci sono voluti un paio di passi aggiunta per convertire l'immagine disco "ospitata" in origine significava per VMware Fusion / Workstation per funzionare correttamente in un vSphere / ambiente basato su vCloud Air. Il CoreOS OVA è attualmente disponibile solo nel canale di CoreOS Alpha per la " produzione di immagini ", che comprende anche open-vm-tools di VMware e l'ultima versione ad oggi è CoreOS 554.0.0 .
È possibile utilizzando il vSphere C # o vSphere client Web per importare il OVA o è possibile automatizzare questo semplicemente utilizzando da riga di comando tramite ovftool. Ecco un frammento di esempio che è possibile eseguire direttamente contro un host ESXi:
Shell
/Applications/VMware\ OVF\ Tool/ovftool \
--name=CoreOS \
"--net:VM Network=VM Network" \
--datastore=mini-local-datastore-2 \
--diskMode=thin \
'http://alpha.release.core-os.net/amd64-usr/554.0.0/coreos_production_vmware_ova.ova' \
'vi://root:vmware123@mini.primp-industries.com'
È inoltre possibile importare la CoreOS OVA in vCloud Air di ma sarà necessario collegare nell'interfaccia vCloud Director per caricare o è anche possibile utilizzare ovftool. Per maggiori dettagli su come importare utilizzando ovftool, controllare la documentazione qui .
Ecco uno screenshot di schierare CoreOS da un catalogo vCloud Air:
Screen shot 2015/01/08 alle 8.39.48 AM
La "produzione" immagine CoreOS non contiene le chiavi SSH insicure come l'immagine "insicuro" e quindi sarà ancora bisogno di creare una configurazione ISO Nube se si desidera personalizzare ulteriormente l'immagine tra cui credenziali di accesso. Potete dare un'occhiata alla sceneggiatura che avevo creato per la distribuzione CoreOS dal canale stabile e per maggiori dettagli consultate il documentazione Nube Config pure.
È possibile utilizzando il vSphere C # o vSphere client Web per importare il OVA o è possibile automatizzare questo semplicemente utilizzando da riga di comando tramite ovftool. Ecco un frammento di esempio che è possibile eseguire direttamente contro un host ESXi:
Shell
/Applications/VMware\ OVF\ Tool/ovftool \
--name=CoreOS \
"--net:VM Network=VM Network" \
--datastore=mini-local-datastore-2 \
--diskMode=thin \
'http://alpha.release.core-os.net/amd64-usr/554.0.0/coreos_production_vmware_ova.ova' \
'vi://root:vmware123@mini.primp-industries.com'
È inoltre possibile importare la CoreOS OVA in vCloud Air di ma sarà necessario collegare nell'interfaccia vCloud Director per caricare o è anche possibile utilizzare ovftool. Per maggiori dettagli su come importare utilizzando ovftool, controllare la documentazione qui .
Ecco uno screenshot di schierare CoreOS da un catalogo vCloud Air:
Screen shot 2015/01/08 alle 8.39.48 AM
La "produzione" immagine CoreOS non contiene le chiavi SSH insicure come l'immagine "insicuro" e quindi sarà ancora bisogno di creare una configurazione ISO Nube se si desidera personalizzare ulteriormente l'immagine tra cui credenziali di accesso. Potete dare un'occhiata alla sceneggiatura che avevo creato per la distribuzione CoreOS dal canale stabile e per maggiori dettagli consultate il documentazione Nube Config pure.
lunedì 5 gennaio 2015
Fun fine dei fatti dell'anno su virtuallyGhetto
Mi sono svegliato alle 6 del mattino la scorsa Domenica senza una ragione apparente. Forse il mio corpo mi sta preparando per la paternità? In ogni caso, non potevo tornare a dormire e ha iniziato a pensare alcuni dei blog che ho scritto lo scorso anno su virtuallyGhetto (finendo il suo 5 ° anno). Con l'anno quasi fine, ho pensato che sarebbe stato bello per verificare alcune delle statistiche su virtuallyGhetto per questo anno e condividere alcuni dei fatti di divertimento con i miei lettori. I dati di seguito sono raccolti da un plugin per WordPress chiamato Jetpack che è un must per tutti i blogger che utilizzano WordPress e il WP Statistics Plugin.
Vorrei anche approfittare di questo momento e dire grazie a tutti i miei sponsor per il sostegno virtuallyGhetto e soprattutto vorrei dire grazie ai miei lettori. Grazie per il vostro impegno se questo sia un commento sul mio blog, una discussione su Twitter, una e-mail descrivendo un problema o semplicemente dire ciao a una conferenza. Grazie a tutti coloro che hanno condiviso storie interessanti, sfide e casi d'uso unica su come si utilizzano i prodotti VMware e continuando per aiutarci a migliorare i nostri prodotti. 2014 è stato un anno fantastico e non vedo l'ora di tutte le cose interessanti a venire nel 2015 oltre a continuare a condividere e contribuire alla comunità attraverso il mio blog. Se ci sono argomenti che vorreste vedermi esplorare ulteriormente o continuare a esplorare il prossimo anno, non esitate a lasciare un commento o mandarmi una mail. Vi auguro un Happy Holidays tand hanno un divertente e sicuro Felice anno nuovo, vediamo tutti nel 2015!
Iscriviti a:
Post (Atom)