L'aggiunta di schermata iniziale del BIOS VSAN personalizzato alla Intel NUC
postato su 2016/03/06
Una delle ultime cose che volevo esaminare dopo aver impostato la mia nuova VSAN 6,2 laboratorio domestico sul nuovo 6 Gen Intel NUC è stato quello di aggiungere una schermata del BIOS Custom Splash dare il mio sistema un tocco personale. Aggiornamento la schermata iniziale del BIOS potrebbe richiedere il ripristino del BIOS stesso, che mi ha dato qualche preoccupazione dopo aver sentito il problema del BIOS V33 in cui la fessura M.2 non sarebbe più essere rilevato dopo l'aggiornamento. Anche se c'era una semplice soluzione dopo l'aggiornamento, ho ancora voglia di essere prudenti. Durante il fine settimana avevo notato che Intel aveva rilasciato BIOS V36 per la Intel NUC, che ha risolto il problema M.2 tra pochi altri. Ho deciso di dare un colpo e spero che io che non lo faccio mattoni mia NUC.
Sono felice di dire che sono riuscito ad aggiornare all'ultima Intel NUC BIOS e come si può vedere dalla schermata qui sotto, sono stato anche in grado di sostituire la schermata iniziale del BIOS Intel default con un capitano VSAN schermata iniziale del BIOS (TV è 46 "per coloro che chiedono):)
custom-VSAN bios-schermata iniziale-per-intel-NUC-0
Il processo per la creazione e la personalizzazione Intel NUC BIOS è relativamente semplice, ma perché ho aspettato fino a dopo che avevo tutto installato, è finito per essere un po 'più lavoro di quanto avevo sperato. Per personalizzare il vostro BIOS, Intel fornisce una unica utility di Microsoft Windows chiamato Intel Integrator Toolkit . Il modo più semplice per costruire e aggiornare il BIOS è quello di iniziare inizialmente fuori con l'installazione di Microsoft Windows su Intel NUC stesso che poi consente a lampeggiare facilmente il BIOS utilizzando il file eseguibile che viene generato dal toolkit. Dato che avevo già consumato entrambi i miei SSD per VMware VSAN e Microsoft Windows non consente di installare il suo sistema operativo direttamente su un dispositivo USB, ho dovuto usare questo metodo qui di installare una versione di avvio di Microsoft Windows sul dispositivo USB da quando ho non ha voluto soffiare via il mio setup VSAN.
OK, ora sulla roba fresca. Di seguito sono elencate le istruzioni su come costruire e personalizzare il BIOS per il processore Intel NUC. Se si desidera utilizzare la schermata iniziale del BIOS stesso esatto, nonché l'aggiornamento all'ultima V36 BIOS e non vogliono passare attraverso il fastidio, ho fatto la mia immagine VSAN BIOS personalizzato disponibile qui . Hai solo bisogno di scaricare l'eseguibile e lanciarlo sul Intel stessa NUC, che deve essere in esecuzione Microsoft Windows (io ho usato 8.1) e poi seguire le schermate a lampeggiare il BIOS.
Fase 1 - Scaricare i seguenti due pacchetti e trasferirli immagine Microsoft Windows in esecuzione sul vostro NUC:
Intel Integrator Toolkit
Intel NUC BIOS V36 (SYSKLi35-86A)
Fase 2 - Installare il Toolkit Intel Integrator e quindi avviare il programma
Fase 3 - Selezionare il " Personalizzare un file del BIOS opzione" e caricare sia l'immagine personalizzata VSAN BIOS che ho messo a disposizione qui OPPURE caricare il file del BIOS V36 NUC si era scaricato in precedenza.
custom-VSAN bios-schermata iniziale-per-intel-NUC-1
Fase 4 - Nell'angolo in basso a sinistra, cercare l'immagine grafica che si desidera utilizzare per la schermata iniziale del BIOS (le immagini con sfondo nero funziona meglio). Per chi fosse interessato, è possibile trovare l'immagine del capitano VSAN che avevo usato qui . Lo strumento supporta in realtà diversi formati di immagine, oltre al default BMP come JPEG e PNG, hai solo bisogno di cambiare il tipo di estensione. C'è un limite di dimensione, ma la cosa bella di questo strumento è che ci sia la possibilità di comprimere l'immagine quando rileva che è troppo grande. Assicurarsi di modificare l'immagine per le quattro diverse opzioni facendo clic sul menu a discesa guidata. Ho pensato che ho avuto solo per sostituire la prima immagine ma sembra che le altre versioni della schermata iniziale viene utilizzato anche ed è meglio per tutti sostituire solo. Hai anche la possibilità di cambiare altre impostazioni di default nel BIOS, sentitevi liberi di fare clic sul suggerimento per i dettagli su ciascuna delle opzioni.
custom-VSAN bios-schermata iniziale-per-intel-NUC-2
Fase 5 - Una volta che hai finito di personalizzare il vostro BIOS, sarà quindi salvare le modifiche e lo strumento produrrà un unico eseguibile di Windows (SY0036.exe), che verrà eseguita sul NUC stesso per il flash del BIOS. Verrà richiesto con un paio di domande e una volta iniziato il processo, si riavvia e sarà necessario confermare ancora una volta prima dell'avvio del processo di imaging. Se tutto fosse successo, si dovrebbe ora vedere una nuova schermata iniziale del BIOS di sostituire l'immagine predefinita di Intel. C'è una buona probabilità che si può passare attraverso questo processo un paio di volte a seconda se si è soddisfatti con il display schermata iniziale. Credo che mi ci sono voluti circa tre tentativi. Spero che questo aiuti tutti coloro che cercano di aggiungere un tocco personale al proprio laboratorio di casa!
martedì 8 marzo 2016
martedì 26 gennaio 2016
Cheatsheet per l'intero VMware AppCatalyst API utilizzando cURL
Ci sono state un paio di domande di recente circa la sintassi richiesta per specifiche operazioni di VMware AppCatalyst quando si consumano l'API REST con cURL. Ho pensato che ho messo insieme un rapido "bigino" che contiene gli esempi Curl per l'intera API VMware AppCatalyst che non solo sarebbe aiutarmi in futuro, ma potrebbe anche beneficiare gli altri. Come molti, ho imparato anche con l'esempio e con i campioni esplicite per iniziare è un ottimo modo per prendere confidenza con una nuova tecnologia o prodotto. Se siete nuovi a VMware AppCatalyst e vorrebbe un breve riassunto su come iniziare rapidamente, assicurati di aver letto il mio articolo arrivare iniziato qui per ulteriori dettagli.
Mentre passa attraverso l'API AppCatalyst, ho trovato un paio di operazioni API che aveva alcune incoerenze e non rispettare rigorosamente il formato JSON. Grazie a Roman Tarnvski per fornire la soluzione. Mi auguro che questi problemi saranno risolti in un futuro aggiornamento AppCatalyst come mi piace la facilità d'uso del loro API. Per la maggior parte delle API, la documentazione di sé tramite l'AppCatalyst API Explorer è accurata, che potete vedere dalla schermata qui sotto.
appcatalyst-api-explorer
Prima di poter interagire con le API REST AppCatalyst, è necessario avviare il AppCatalyst Daemon eseguendo il seguente comando:
/ opt / vmware / appcatalyst / bin / appcatalyst-daemon
Una volta che il AppCatalyst Daemon è in esecuzione, è possibile aprire un nuovo terminale e iniziare a lavorare con la REST API via cURL o qualsiasi altro strumento di scelta.
1. Creare una nuova VM dal modello Photon operativo VM predefinito:
È tecnicamente sufficiente specificare l'unico "id proprietà", ma si può anche dare un nome visualizzato per la VM utilizzando il "nome proprietà".
ricciolo -d '{"id": "VM1", "name": "MyAppCat-VM1"}' -X POST localhost: 8080 / api / vms
1. CreateVM
2. Clone una VM da una VM esistente:
Simile alla creazione di una nuova VM, avete anche possibilità di utilizzare il "tag proprietà" per associare metadati aggiuntivi con la VM.
ricciolo -d '{"id": "VM2", "parentid": "VM1", "name": "MyAppCat-VM2", "tag": "Sviluppo"}' -X POST localhost: 8080 / api / vms
2. Clone VM
3. Elenco tutte le macchine virtuali
ricciolo -X GET localhost: 8080 / api / vms
3. Elenco VM
4. Ottenere una specifica VM:
Per recuperare una specifica VM, è necessario accendere il VM prima è consentita questa operazione. Ho trovato strano che questo era il caso, ma forse questo potrebbe essere migliorato in futuro, di non avere questo requisito, soprattutto se si vuole tirare fuori i dettagli, come la proprietà "tag".
arricciatura -X GET localhost: 8080 / API / VMS / VM1
4. Ottenere specifica VM
5. Accendere un VM:
ricciolo -d 'su' -X PATCH localhost: 8080 / api / VMS / potere / VM1
Nota: Altri VM Filiera Energia: off, arresto, sospensione, mettere in pausa e Riattiva
5. Alimentazione VM
6. Ottenere lo stato di alimentazione di una macchina virtuale:
ricciolo -X GET localhost: 8080 / api / VMS / potere / VM1
6. Ottenere statale
7. Prendi l'indirizzo IP di una macchina virtuale:
ricciolo -X GET localhost: 8080 / api / VMS / VM1 / ipaddress
7. Ottieni indirizzo IP
8. Abilitare la condivisione delle cartelle per una macchina virtuale:
ricciolo -d "vero" -X PATCH localhost: 8080 / API / VMS / VM1 / cartelle
8. Abilitare cartelle condivise
9. Creare una mappatura cartella condivisa per una macchina virtuale:
La "guestPath proprietà" non è un percorso assoluto all'interno del GuestOS, ma piuttosto un nome logico. Per ulteriori dettagli sulle cartelle condivise in AppCatalyst, si prega di dare un'occhiata a questo articolo qui. Attualmente c'è un solo "bandiere proprietà" con il valore di 4, che abilita di lettura / scrittura, consultare l'articolo del link qui sopra per maggiori dettagli sulla condivisione delle cartelle in AppCatalyst.
ricciolo -d '{"guestPath": "-cartella condivisa", "HostPath": "/ Users / WLAM / git", "bandiere": 4}' -X POST localhost: 8080 / API / VMS / VM1 / cartelle
9. Creare cartella condivisa
10. Elenco tutte le cartelle condivise di una VM:
ricciolo -X GET localhost: 8080 / API / VMS / VM1 / cartelle
10. Elenco tutte le cartelle condivise
11. Elenco una cartella condivisa specifica per un VM:
ricciolo -X GET localhost: 8080 / api / VMS / VM1 / cartelle /-cartella condivisa
11. Lista cartella condivisa specifica
12. Eliminare una cartella condivisa per una macchina virtuale:
ricciolo -X DELETE localhost: 8080 / API / VMS / VM1 / cartelle /-cartella condivisa
12. Elimina cartella condivisa
13. Elimina VM:
ricciolo -X DELETE localhost: 8080 / API / VMS / VM1
13. Elimina VM
Mentre passa attraverso l'API AppCatalyst, ho trovato un paio di operazioni API che aveva alcune incoerenze e non rispettare rigorosamente il formato JSON. Grazie a Roman Tarnvski per fornire la soluzione. Mi auguro che questi problemi saranno risolti in un futuro aggiornamento AppCatalyst come mi piace la facilità d'uso del loro API. Per la maggior parte delle API, la documentazione di sé tramite l'AppCatalyst API Explorer è accurata, che potete vedere dalla schermata qui sotto.
appcatalyst-api-explorer
Prima di poter interagire con le API REST AppCatalyst, è necessario avviare il AppCatalyst Daemon eseguendo il seguente comando:
/ opt / vmware / appcatalyst / bin / appcatalyst-daemon
Una volta che il AppCatalyst Daemon è in esecuzione, è possibile aprire un nuovo terminale e iniziare a lavorare con la REST API via cURL o qualsiasi altro strumento di scelta.
1. Creare una nuova VM dal modello Photon operativo VM predefinito:
È tecnicamente sufficiente specificare l'unico "id proprietà", ma si può anche dare un nome visualizzato per la VM utilizzando il "nome proprietà".
ricciolo -d '{"id": "VM1", "name": "MyAppCat-VM1"}' -X POST localhost: 8080 / api / vms
1. CreateVM
2. Clone una VM da una VM esistente:
Simile alla creazione di una nuova VM, avete anche possibilità di utilizzare il "tag proprietà" per associare metadati aggiuntivi con la VM.
ricciolo -d '{"id": "VM2", "parentid": "VM1", "name": "MyAppCat-VM2", "tag": "Sviluppo"}' -X POST localhost: 8080 / api / vms
2. Clone VM
3. Elenco tutte le macchine virtuali
ricciolo -X GET localhost: 8080 / api / vms
3. Elenco VM
4. Ottenere una specifica VM:
Per recuperare una specifica VM, è necessario accendere il VM prima è consentita questa operazione. Ho trovato strano che questo era il caso, ma forse questo potrebbe essere migliorato in futuro, di non avere questo requisito, soprattutto se si vuole tirare fuori i dettagli, come la proprietà "tag".
arricciatura -X GET localhost: 8080 / API / VMS / VM1
4. Ottenere specifica VM
5. Accendere un VM:
ricciolo -d 'su' -X PATCH localhost: 8080 / api / VMS / potere / VM1
Nota: Altri VM Filiera Energia: off, arresto, sospensione, mettere in pausa e Riattiva
5. Alimentazione VM
6. Ottenere lo stato di alimentazione di una macchina virtuale:
ricciolo -X GET localhost: 8080 / api / VMS / potere / VM1
6. Ottenere statale
7. Prendi l'indirizzo IP di una macchina virtuale:
ricciolo -X GET localhost: 8080 / api / VMS / VM1 / ipaddress
7. Ottieni indirizzo IP
8. Abilitare la condivisione delle cartelle per una macchina virtuale:
ricciolo -d "vero" -X PATCH localhost: 8080 / API / VMS / VM1 / cartelle
8. Abilitare cartelle condivise
9. Creare una mappatura cartella condivisa per una macchina virtuale:
La "guestPath proprietà" non è un percorso assoluto all'interno del GuestOS, ma piuttosto un nome logico. Per ulteriori dettagli sulle cartelle condivise in AppCatalyst, si prega di dare un'occhiata a questo articolo qui. Attualmente c'è un solo "bandiere proprietà" con il valore di 4, che abilita di lettura / scrittura, consultare l'articolo del link qui sopra per maggiori dettagli sulla condivisione delle cartelle in AppCatalyst.
ricciolo -d '{"guestPath": "-cartella condivisa", "HostPath": "/ Users / WLAM / git", "bandiere": 4}' -X POST localhost: 8080 / API / VMS / VM1 / cartelle
9. Creare cartella condivisa
10. Elenco tutte le cartelle condivise di una VM:
ricciolo -X GET localhost: 8080 / API / VMS / VM1 / cartelle
10. Elenco tutte le cartelle condivise
11. Elenco una cartella condivisa specifica per un VM:
ricciolo -X GET localhost: 8080 / api / VMS / VM1 / cartelle /-cartella condivisa
11. Lista cartella condivisa specifica
12. Eliminare una cartella condivisa per una macchina virtuale:
ricciolo -X DELETE localhost: 8080 / API / VMS / VM1 / cartelle /-cartella condivisa
12. Elimina cartella condivisa
13. Elimina VM:
ricciolo -X DELETE localhost: 8080 / API / VMS / VM1
13. Elimina VM
martedì 5 gennaio 2016
Come bootstrap del VCSA utilizzando il client incorporato ESXi host?
In passato, ho scritto sui vari modi di "bootstrapping" vCenter Server (qui e qui), che può essere utile per la creazione di distribuzioni vSphere greenfield. Questo argomento è sempre stato di interesse per me, perché può essere il più difficile da risolvere, soprattutto quando si inizia solo con un singolo host ESXi. Storicamente, queste opzioni "bootstrap" sono per lo più stati cacciati da un punto di vista CLI che non è una brutta cosa quando si pensa a questo proposito dal punto di vista di automazione e che hanno bisogno di replicare questo un paio dozzina di volte. Tuttavia, dal punto di vista dell'utente esperienza, potrebbe non essere così ideale, soprattutto se questo è un compito frequente. Una delle altre funzioni interessanti del Cliente ESXi host incorporato (EHC) che recentemente ha avuto il suo rilascio v4 è che può essere utilizzato per distribuire appliance virtuali memorizzati in formato OVF.
Distribuzione OVF era stato intorno dal v2 di EHC se non ricordo male, ma non ha sostenuto tutti i diversi tipi di funzionalità OVF, come opzione di distribuzione come un esempio fino a più di recente. Una delle difficoltà con il supporto OVF su ESXi non è solo sostenendo la possibilità di importare / esportare ma è anche sostenendo la specifica completa OVF che ESXi attualmente non supporta oggi. Ciò significa, per fornire il pieno supporto OVF attraverso EHC, avrebbe dovuto implementare una funzionalità simile a quello che fa ovftool oggi con l'opzione di --injectOvfEnv. Per fortuna, questo era qualcosa che è stato aggiunto molto presto in base alla mia retroazione che a mio parere è fondamentale quando si tratta di greenfield implementazioni e uno dei casi d'uso di base che vedo per EHC.
Senza ulteriori indugi, di seguito le istruzioni per il bootstrap Appliance vCenter Server (VCSA) utilizzando il client di Host incorporato.
Fase 1 - Scarica il VCSA OVA e quindi convertirlo in un OVF utilizzando 7zip o ovftool. Il motivo è necessario convertirlo in un OVF è che c'è attualmente un problema noto quando si cerca di estrarre OAV più grandi all'interno del EHC. In questo modo, è anche accelerare il tempo necessario per eseguire l'upload e non dover aspettare per l'interfaccia utente per estrarlo nel formato attuale di consumo, che è la OVF e VMDK.
Fase 2 - Fare clic sull'opzione "Crea / Registrati VM" e quindi scegliere "Distribuire una macchina virtuale da un OVF o OVA file". È necessario specificare il nome per il VCSA insieme al OVF e le 3 VMDK che è incluso se si utilizza vSphere 6.0 / 6.0 Update 1.
implementare-vcsa-con-embedded-host-client-1
Fase 3 - Successivamente sarà configurare la rete VM e l'opzione del disco di provisioning. Vi verrà anche richiesto di selezionare il "Tipo di distribuzione", che è un'opzione in vSphere 6.0 / 6.0 Update 1 che permette di specificare se si distribuisce un VCSA incorporato, vCenter Server esterno o esterno Piattaforma di servizi Controller (PSC). Si può notare il menu comprende giù le voci duplicate e la ragione di questo è come il VCSA OVA stato costruito, che ri-utilizza la stessa descrizione di ciascuna delle etichette, ma che in realtà hanno significati diversi. Qui di seguito un breve tabella dei mapping corrette l'ordinamento corrente analizzato da EHC ai diversi tipi di VCSA di distribuzione:
Etichetta Actual tipo di distribuzione
Piccoli (fino a 10 host 100 VM) Incorporato Nodo VCSA
I piccoli (fino a 100 host 1K VM) Incorporato Nodo VCSA
Medie (fino a 400 host 4K VM) Incorporato Nodo VCSA
Grandi (fino a 1K host 10K VM) Incorporato Nodo VCSA
Piccoli (fino a 10 host 100 VM) Nodo vCenter server esterno
I piccoli (fino a 100 host 1K VM) Nodo vCenter server esterno
Medie (fino a 400 host 4K VM) Nodo vCenter server esterno
Grandi (fino a 1K host 10K VM) Nodo vCenter server esterno
implementare-vcsa-con-embedded-host-client-2
Fase 4 - Sarà necessario compilare le proprietà OVF che sono necessari per configurare correttamente il VCSA. Le 3 sezioni seguenti sono SOLO quelli è necessario modificare per l'installazione:
Configurazione di rete
Configurazione SSO
Configurazione di sistema
Passo 4a - La sezione Configurazione di rete richiederà di specificare quanto segue:
Host IP Network Address Family - IPv4 o IPv6
Host Modalità di rete - statico o DHCP
Indirizzo Host IP Network - indirizzo IP del VCSA
Host prefisso di rete - Questa è la notazione CIDR della rete si prevede di collocare la VCSA su. Esempio potrebbe essere / 24 (255.255.255.0), che è necessario specificare come solo 24
Host Rete Default Gateway - Gateway da utilizzare
Host server DNS di rete - server DNS da utilizzare
Host Network Identity (opzionale) - Questo è il nome di dominio completo del VCSA. Se siete in un ambiente abilitato DHCP, è possibile lasciare questo vuoto che si utilizza automaticamente localhost.localdomain
implementare-vcsa-con-embedded-host-client-3
Fase 4b - La sezione Configurazione SSO richiederà di specificare quanto segue:
Directory Password - SSO password di amministratore
Elenco password conferma - SSO password di amministratore
Directory Domain Name - SSO Dominio (selezionare vsphere.local se si desidera che il difetto che consiglio)
Nome sito - Nome SSO sito
Nuova identità Dominio - Ciò è necessario se si tratta di una nuova messa a punto e non si sta impostando la replica SSO con un PSC esistente
implementare-vcsa-con-embedded-host-client-4
Fase 4c - La sezione di configurazione di sistema richiederà di specificare quanto segue:
Root Password - La password di root per il sistema operativo
Password di root conferma - La password di root per il sistema operativo
SSH abilitato (opzionale) - Se si desidera per SSH sia abilitato dopo la distribuzione
Strumenti basati su Time Sync Abilitato - Se non si dispone di un server NTP, è necessario selezionare questa opzione
I server NTP (opzionale) - Specificare un server NTP valido che si desidera utilizzare
implementare-vcsa-con-embedded-host-client-5
Fase 5 - Avrete la possibilità di rivedere le configurazioni prima di iniziare la distribuzione. Si dovrebbe controllare due volte a garantire che tutte le proprietà OVF sono corrette, altrimenti si può ottenere una distribuzione non riuscita.
implementare-vcsa-con-embedded-host-client-6
Fase 6 - Una volta pronti, andare avanti e fare clic sul pulsante "Fine". Verrà avviata l'importazione OVF quale è possibile monitorare utilizzando il riquadro Attività recenti. Come parte del flusso di lavoro OVF / OVA, una volta che l'importazione è stata completata, esso si accenderà automaticamente la VM per voi. Si prega di non interrompere questo processo come EHC sarà iniettando le proprietà OVF si era specificato in precedenza al VM per garantire la VCSA sarà configurato correttamente.
implementare-vcsa-con-embedded-host-client-7
Una volta che la VM è stato acceso, è possibile fare clic nella console VM per visualizzare lo stato della fase costitutiva e si spera in un paio di minuti, si avrà una configurazione completa e funzionale VCSA pronto per l'uso!
implementare-vcsa-con-embedded-host-client-8
Anche se EHC oggi ha messo in atto una bella interfaccia generica / OVA OVF nell'interfaccia utente per supportare quasi tutte le OVF / OVA, si può vedere come questo potrebbe essere ulteriormente migliorata specificatamente per le distribuzioni VCSA dal punto di vista l'esperienza degli utenti. Chi lo sa, questo potrebbe ottenere ancora più semplice in futuro:)
Distribuzione OVF era stato intorno dal v2 di EHC se non ricordo male, ma non ha sostenuto tutti i diversi tipi di funzionalità OVF, come opzione di distribuzione come un esempio fino a più di recente. Una delle difficoltà con il supporto OVF su ESXi non è solo sostenendo la possibilità di importare / esportare ma è anche sostenendo la specifica completa OVF che ESXi attualmente non supporta oggi. Ciò significa, per fornire il pieno supporto OVF attraverso EHC, avrebbe dovuto implementare una funzionalità simile a quello che fa ovftool oggi con l'opzione di --injectOvfEnv. Per fortuna, questo era qualcosa che è stato aggiunto molto presto in base alla mia retroazione che a mio parere è fondamentale quando si tratta di greenfield implementazioni e uno dei casi d'uso di base che vedo per EHC.
Senza ulteriori indugi, di seguito le istruzioni per il bootstrap Appliance vCenter Server (VCSA) utilizzando il client di Host incorporato.
Fase 1 - Scarica il VCSA OVA e quindi convertirlo in un OVF utilizzando 7zip o ovftool. Il motivo è necessario convertirlo in un OVF è che c'è attualmente un problema noto quando si cerca di estrarre OAV più grandi all'interno del EHC. In questo modo, è anche accelerare il tempo necessario per eseguire l'upload e non dover aspettare per l'interfaccia utente per estrarlo nel formato attuale di consumo, che è la OVF e VMDK.
Fase 2 - Fare clic sull'opzione "Crea / Registrati VM" e quindi scegliere "Distribuire una macchina virtuale da un OVF o OVA file". È necessario specificare il nome per il VCSA insieme al OVF e le 3 VMDK che è incluso se si utilizza vSphere 6.0 / 6.0 Update 1.
implementare-vcsa-con-embedded-host-client-1
Fase 3 - Successivamente sarà configurare la rete VM e l'opzione del disco di provisioning. Vi verrà anche richiesto di selezionare il "Tipo di distribuzione", che è un'opzione in vSphere 6.0 / 6.0 Update 1 che permette di specificare se si distribuisce un VCSA incorporato, vCenter Server esterno o esterno Piattaforma di servizi Controller (PSC). Si può notare il menu comprende giù le voci duplicate e la ragione di questo è come il VCSA OVA stato costruito, che ri-utilizza la stessa descrizione di ciascuna delle etichette, ma che in realtà hanno significati diversi. Qui di seguito un breve tabella dei mapping corrette l'ordinamento corrente analizzato da EHC ai diversi tipi di VCSA di distribuzione:
Etichetta Actual tipo di distribuzione
Piccoli (fino a 10 host 100 VM) Incorporato Nodo VCSA
I piccoli (fino a 100 host 1K VM) Incorporato Nodo VCSA
Medie (fino a 400 host 4K VM) Incorporato Nodo VCSA
Grandi (fino a 1K host 10K VM) Incorporato Nodo VCSA
Piccoli (fino a 10 host 100 VM) Nodo vCenter server esterno
I piccoli (fino a 100 host 1K VM) Nodo vCenter server esterno
Medie (fino a 400 host 4K VM) Nodo vCenter server esterno
Grandi (fino a 1K host 10K VM) Nodo vCenter server esterno
implementare-vcsa-con-embedded-host-client-2
Fase 4 - Sarà necessario compilare le proprietà OVF che sono necessari per configurare correttamente il VCSA. Le 3 sezioni seguenti sono SOLO quelli è necessario modificare per l'installazione:
Configurazione di rete
Configurazione SSO
Configurazione di sistema
Passo 4a - La sezione Configurazione di rete richiederà di specificare quanto segue:
Host IP Network Address Family - IPv4 o IPv6
Host Modalità di rete - statico o DHCP
Indirizzo Host IP Network - indirizzo IP del VCSA
Host prefisso di rete - Questa è la notazione CIDR della rete si prevede di collocare la VCSA su. Esempio potrebbe essere / 24 (255.255.255.0), che è necessario specificare come solo 24
Host Rete Default Gateway - Gateway da utilizzare
Host server DNS di rete - server DNS da utilizzare
Host Network Identity (opzionale) - Questo è il nome di dominio completo del VCSA. Se siete in un ambiente abilitato DHCP, è possibile lasciare questo vuoto che si utilizza automaticamente localhost.localdomain
implementare-vcsa-con-embedded-host-client-3
Fase 4b - La sezione Configurazione SSO richiederà di specificare quanto segue:
Directory Password - SSO password di amministratore
Elenco password conferma - SSO password di amministratore
Directory Domain Name - SSO Dominio (selezionare vsphere.local se si desidera che il difetto che consiglio)
Nome sito - Nome SSO sito
Nuova identità Dominio - Ciò è necessario se si tratta di una nuova messa a punto e non si sta impostando la replica SSO con un PSC esistente
implementare-vcsa-con-embedded-host-client-4
Fase 4c - La sezione di configurazione di sistema richiederà di specificare quanto segue:
Root Password - La password di root per il sistema operativo
Password di root conferma - La password di root per il sistema operativo
SSH abilitato (opzionale) - Se si desidera per SSH sia abilitato dopo la distribuzione
Strumenti basati su Time Sync Abilitato - Se non si dispone di un server NTP, è necessario selezionare questa opzione
I server NTP (opzionale) - Specificare un server NTP valido che si desidera utilizzare
implementare-vcsa-con-embedded-host-client-5
Fase 5 - Avrete la possibilità di rivedere le configurazioni prima di iniziare la distribuzione. Si dovrebbe controllare due volte a garantire che tutte le proprietà OVF sono corrette, altrimenti si può ottenere una distribuzione non riuscita.
implementare-vcsa-con-embedded-host-client-6
Fase 6 - Una volta pronti, andare avanti e fare clic sul pulsante "Fine". Verrà avviata l'importazione OVF quale è possibile monitorare utilizzando il riquadro Attività recenti. Come parte del flusso di lavoro OVF / OVA, una volta che l'importazione è stata completata, esso si accenderà automaticamente la VM per voi. Si prega di non interrompere questo processo come EHC sarà iniettando le proprietà OVF si era specificato in precedenza al VM per garantire la VCSA sarà configurato correttamente.
implementare-vcsa-con-embedded-host-client-7
Una volta che la VM è stato acceso, è possibile fare clic nella console VM per visualizzare lo stato della fase costitutiva e si spera in un paio di minuti, si avrà una configurazione completa e funzionale VCSA pronto per l'uso!
implementare-vcsa-con-embedded-host-client-8
Anche se EHC oggi ha messo in atto una bella interfaccia generica / OVA OVF nell'interfaccia utente per supportare quasi tutte le OVF / OVA, si può vedere come questo potrebbe essere ulteriormente migliorata specificatamente per le distribuzioni VCSA dal punto di vista l'esperienza degli utenti. Chi lo sa, questo potrebbe ottenere ancora più semplice in futuro:)
martedì 24 marzo 2015
Guida automazione ultimo di distribuire VCSA 6.0 Parte 4: vCenter Node Management Server
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
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
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:)
Iscriviti a:
Post (Atom)