giovedì 27 marzo 2014

COSA È SUCCESSO A "ESSERE PRUDENTI IN QUELLO CHE FAI"?

Un commento di Pieter E. Smit sul mio vSphere non ha bisogno di Bandaids GAL inserisci aperto ancora un altro vaso di Pandora: comportamento vSphere sul recupero uplink.
Breve riassunto : vSphere inizia con un uplink, non appena il suo livello fisico diventa operativo, che potrebbero accadere durante TR fase di startup switch o prima di una porta switch ToR entra inoltro di Stato.
Molti dispositivi verificare la disponibilità di livello superiore prima di iniziare a utilizzare un collegamento di rete fisica point-to-point. Tali meccanismi potrebbero funzionare a livello 2 (esempio: LACP o UDLD) o al di sopra - da allocazione degli indirizzi basata su DHCP a bloccare - ascolto - apprendimento - inoltro transizione di stato di STP e adiacenze esplicite formate dalla maggior parte dei protocolli di routing moderni. Utilizzando un collegamento solo perché l'hardware rileva un segnale portante è spesso troppo rischioso, soprattutto per un dispositivo che sostiene di essere un interruttore con decine di server dietro di esso.
Ovviamente regole diverse si applicano alle reti x86 (o almeno alcune varianti semplicistiche di esso ) - siete liberi di utilizzare un collegamento per il traffico degli utenti, non appena è possibile avviare l'invio di pacchetti, e quando gli utenti iniziano a lamentarsi, si ottiene una raccomandazione utilizzare failback manuale e modificare la configurazione interruttore . Bisogna chiedersi quando l' essere conservatore in ciò che si fa principio si è perso.
Sto raccogliendo su VMware, ma ho perso altri sistemi operativi positivi non sono molto meglio. Se sono, scrivete un commento.
VMware finalmente implementato un meccanismo ragionevole in ESXi 5.0 - un ritardo di link-up configurabile. Peccato che il suo valore predefinito è troppo basso, è nascosto da qualche parte nella scheda Impostazioni avanzate, e l'unica documentazione è un arcanoarticolo della knowledge base . Avere una sonda CFM attivo tra uplink appartenenti agli stessi gruppi di porte (non costante beaconing , solo un test di link-ready-for-forwarding) sarebbe ancora meglio, ma probabilmente è troppo sperare per ... o no?

lunedì 24 marzo 2014

Avendo difficoltà Abilitazione Nested ESXi in vSphere 5.1?

Ho notato che c'erano un paio di persone che hanno qualche difficoltà consentendo Nested ESXi (AAT virtualizzazione hardware virtuale) nella ultima versione di ESXi 5.1 e ho pensato di condividere alcune informazioni e consigli sulla risoluzione dei problemi di installazione nel caso in cui si esegue in problemi simili supplementare.
*** DISCLAIMER **** Questo non è ufficialmente supportato da VMware, non si preoccupano chiedendo se è supportato o chiamando in supporto VMware per i dettagli o aiuto.
Se si desidera eseguire ESXi nidificato o di altri hypervisor su ESXi 5.1 ed eseguire a 32 bit macchine virtuali nidificati, è necessario soddisfare i seguenti requisiti hardware:
  • CPU supporto Intel VT-x o AMD-V
Se si desidera eseguire annidati macchine virtuali a 64 bit nel vostro ESXi nested o altri hypervisor, oltre al requisito di cui sopra, è necessario soddisfare i seguenti requisiti hardware:
  • CPU supporto Intel EPT o AMD RVI
Se si soddisfano solo il primo criterio, si POTETE ancora installato ESXi nested o di altri hypervisor su ESXi 5.1, MAsarà solo in grado di funzionare a 32 bit macchine virtuali nidificate. Quando si crea la shell macchina virtuale usando il nuovo vSphere client Web, nella vista espansa CPU, la " virtualizzazione hardware box "sarà disattivata.Questo è atteso come non hai il supporto completo per AAT, ma è ancora possibile continuare con l'installazione di ESXi o di altri hypervisor.
In ESXi 5.0, potrebbe essere stato in grado di funzionare a 64 bit macchine virtuali annidate senza supporto EPT / RVI, ma la performance è stata estremamente povera. Con ESXi 5.1, AAT ora richiede EPT / RVI.
Nota: Durante l'installazione di ESXi, è possibile visualizzare il seguente messaggio " No Hardware Virtualization Support ", si può semplicemente ignorarlo.
Se si utilizza siti come ark.intel.com di Intel per controllare i requisiti di CPU, essere consapevoli del fatto che ècomune anche per i fornitori di hardware di pubblicare informazioni non corrette sui loro siti web. Tuttavia, c'è un modo veloce è possibile convalidare sul vostro host ESXi se avete il pieno sostegno AAT.
In vSphere 5.1, c'è una nuova proprietà funzionalità denominata  nestedHVSupported che specifica se il vostro ESXi 5.1 host fisico ha pieno supporto AAT. Questa struttura sarà vero solo SE la tua CPU ha sia Intel-VT + EPT o AMD-V + RVI . Un modo semplice e veloce per convalidare questo sta usando il MOB vSphere per recuperare il valore.
Per controllare nestedHVSupported proprietà, inserisci i dati seguenti in un browser web (sostituire l'indirizzo IP / nome host del vostro host ESXi):
https://himalaya.primp-industries.com/mob/?moid=ha-host&doPath=capability
Dopo aver effettuato il login, cercare il nestedHVSupported proprietà sulla pagina e si dovrebbe vedere un valore vero o falso. Come accennato in precedenza, se è falso, si potrebbe ancora essere in grado di installare ESXi nested o di altri hypervisor, ma non sarà in grado di eseguire annidati macchine virtuali a 64 bit. Consiglierei anche di dare un'occhiata al vostro BIOS di sistema per assicurare le cose come Intel-VT/EPT e AMD-V/RVI sono attivati ​​e, a volte potrebbe essere solo semplice come un aggiornamento del BIOS (si può sempre verificare contattando il fornitore di hardware se avete ulteriori domande).
Per la connettività di rete corretto, assicurarsi anche che sia il vostro vSwitch standard o Distributed Virtual Switch ha sia la modalità promiscua e trasmissione forgiato abilitati sia globalmente sul portgroup o distribuito portgroup tuoi nidificati host ESXi sono collegati a.

venerdì 21 marzo 2014

Automatizzare ESXi 4.1 Kickstart Tips & Tricks

Durante il test la nuova funzionalità kickstart in ESXi 4.1, mi sono imbattuto in alcuni problemi cercando di convertire una distribuzione classica ESX 4.x per ESXi 4.1. Ho pensato di condividere alcuni dei suggerimenti e trucchi che ho imparato, in modo che altri non voglio incontrare gli stessi problemi.
Prima di tuffarsi in e creando un 4.1 configurazione kickstart ESXi, assicuratevi di trascorrere qualche ora di andare oltre la documentazione fornita da VMware, in particolare il ESXi installabile e Guida di installazione vCenter Server. 
UPDATE: Per ESXi 5, Partenza ESXi5 Kickstart Tips & Tricks
Suggerimento # 1
Se avete intenzione di specificare un ks.cfg (file di configurazione kickstart) nel file pxelinux, assicurarsi che la voce kickstart viene aggiunto dopo l'* vmkboot.gz * ma prima * vmkernel.gz * voce come evidenziato in verde nella schermata . Se lo si inserisce in qualsiasi altra parte l'opzione della riga di boot, si riceverà un errore che non è facile da diagnosticare. Inoltre, si vuole fare in modo di aggiungere trattini triple ( - ) dopo la linea di kickstart seguendo la sintassi richiesta per le opzioni di avvio come evidenziato in arancione nello screenshot.
Suggerimento # 2
Durante lo sviluppo e il test ks.cfg, si consiglia di utilizzare il nuovo DryRun parametro che analizza il file di configurazione kickstart alla ricerca di errori di sintassi e di formattazione. In modalità DryRun, nessuna installazione verrà eseguita, ma vi verrà fornito con un log di se il vostro ks.cfg avesse eventuali errori, avvisi o ha avuto successo in fase di convalida.
La seguente immagine mostra un messaggio di avviso in cui ho volutamente lasciato fuori -hostname voce che viene generalmente raccomandato all'interno della porzione di "rete" del ks.cfg:
Se ci sono altri errori o avvisi, verranno visualizzati all'interno di questa schermata e si può accedere all'host per visualizzare il registro per maggiori dettagli ( esxi_install.log ):
Per accedere all'host, potrete premere il tasto "invio" e verrà richiesto per il login (premere Alt + F1 per passare alla schermata di accesso). Il nome utente di default sarà "root" e la password è vuota, basta premere Invio per la password:
Una volta effettuato il login, si vuole dare un'occhiata al esxi_install.log per maggiori dettagli su come il vostro ks.cfg viene elaborato e se ci sono eventuali errori o avvisi rilevati dal parser:
Suggerimento # 3
Se si desidera attivare sia locale che remoto (accesso SSH) Modalità di supporto tecnico sul vostro host ESXi, ora avete la possibilità di farlo tramite i servizi di accoglienza. È possibile utilizzare il vim-cmd utility (vimsh) per attivare questi servizi e sia TSM locale e remoto è disabilitato per impostazione predefinita.
Nota: Se si desidera attivare o locale e / o remoto TSM, è necessario assicurarsi di attivare e avviare il servizio per voi di essere effettivamente in grado di SSH nel vostro host ESXi.
Suggerimento # 4
Con ESX classico, se avete bisogno di trasferire pacchetti aggiuntivi o file al vostro ospite, si potrebbe facilmente montare un volume NFS, con ESXi, un client NFS non è disponibile. Se il bisogno di trasferire i file per la configurazione, è possibile utilizzare il wget utilità.
La sintassi per wget è il seguente:
wget http://webserver/file-O / tmp / file di
Suggerimento # 5
Mi è stato detto da un sostegno che non si poteva configurare syslog per il vostro host ESXi senza affidarsi a strumenti esterni come vCLI, PowerCLI o vSphere Client. Ho scoperto che in realtà si può configurare configurazioni syslog, anche se bisogna scavare un po 'in vim-cmd (vimsh) in quanto non è disponibile utilizzando uno qualsiasi dei comandi esxcfg-* locali. C'è solo tre opzioni syslog come forniti tramite vSphere Client Configurazioni Advanced Host: Syslog.Remote.Hostname , Syslog.Remote.Port e Syslog.Local.DatastorePath
Ecco la sintassi per le opzioni syslog:
vim-cmd hostsvc / advopt / aggiornare stringa Syslog.Remote.Hostname syslog.primp-industries.com 
vim-cmd hostsvc / advopt / aggiornare Syslog.Remote.Port int 514 
vim-cmd hostsvc / advopt / aggiornare stringa Syslog.Local.DatastorePath "[DataStoreName] / logfiles / hostName.log"
Nota: Attualmente è possibile configurare un solo server syslog per il vostro host ESXi di trasmettere registri per.
Suggerimento # 6
Un altro nuovo nuovo parametro kickstart introdotta con ESXi 4.1 è di livello che viene utilizzato in combinazione con% firstboot strofa. Questo parametro specifica l'ordine specifico in cui le configurazioni firstboot kickstart dovrebbero correre rispetto agli altri script di avvio quando i tuoi ESXi ospitano primi stivali. Per impostazione predefinita, se si lascia questo fuori, VMware creerà automaticamente uno script chiamato firstboot_001 e il numero è 999, che sarà l'ultimo script da eseguire. E 'una buona idea per spostare tutte le configurazioni postali fino alla fine, poiché la maggior parte di configurazione post possono contare su specifici CLI e servizi che devono essere avviati prima di eseguire VMware. È ovviamente possibile modificare il livello, ma attenzione sullo spostamento troppo presto nel processo di avvio.
Ecco un esempio di cambiare il livello di 998:
Una volta che l'host ha avviato, è possibile accedere per vedere lo script che è stato creato dal tuo% firstboot strofa in / etc / vmware / init / init.d
Nota: Come potete vedere, lo script firstboot ora è cambiato a 998. Noterete anche altri due script fissati a livello 999 che gestisce l'aggiornamento della password se si decide di impostare una password di root dal default vuoto, che si dovrebbe. Questi script personalizzati vengono generati dopo la generazione iniziale e al successivo riavvio, questi verranno automaticamente rimossi.
Suggerimento # 7
Si sarà notato in Tip # 6, abbiamo cambiato il livello di 998, per impostazione predefinita, tutti e tre questi init script sono impostati per l'avvio ordine 999. Questo in realtà è stato fatto di proposito, la ragione è come descritto in precedenza, la password di root è vuota per impostazione predefinita. Un problema che ho trovato durante il test è l'incapacità di attivare "Traffic Management" per un'interfaccia VMkernel. Si può facilmente attivare vMotion e FT traffico per un'interfaccia VMkernel utilizzando vim-cmd (vimsh), ma non è possibile per la gestione del traffico. Un modo ho risolto questo problema è la creazione di uno script python che si collega alla ESXi locale MOB e consente di gestione del traffico su una particolare interfaccia VMkernel. Ho condiviso questo script specifico sulla sulle comunità VMTN che possono essere trovati qui . Lo script è in realtà basata sulla versione modificata che è stato inizialmente creato da Justin Guidroz che bloggato su di esso qui .
Ecco il frammento che dovrebbe essere incluso nel firstboot% in cui non richiede di esporre la password di root in quanto è vuota di default:
ESXi 4.1
ESXi 4.1 Update 1 (Richiede CSRF aggiornamento del codice)
Come potete vedere, abbiamo prima creato lo script python e poi eseguirlo. Questo ci permette di chiamare altre utilità all'interno della console Busybox senza dover specificare l'interprete ad essere python, possiamo semplicemente usare busybox come interprete.
Tip # 7a Ecco una soluzione alternativa per consentire la gestione tipo di traffico su ESXi - Un altro modo per abilitare la gestione del traffico su ESXi
Suggerimento # 8
Se si è tentato di configurare NTP ribadendo i server NTP in / etc / ntpd.conf e riavviare ntpd, si noterà che le modifiche non hanno effetto. L'unico modo che ho potuto ottenere questo lavoro è mediante l'emissione di un altro riavvio che è specificato alla fine del firstboot% che verrà poi raccolto su di avvio dall'host.
Suggerimento # 9
Se volete personalizzare la schermata iniziale DCUI, dare un'occhiata al mio post sul blog Come aggiungere un tocco di colore a ESXi DCUI Schermata di benvenuto .
Suggerimento # 10
Se si desidera aggiornare il nome datastore predefinito da "Datastore1" per qualcosa di più utile, come [hostname]-local-storage-1, è possibile utilizzare vim-cmd (vimsh) per farlo. Ecco la sintassi del comando, se si desidera utilizzare il nome host breve e aggiungere "-local-storage-1" (questo dovrebbe essere fatto nella sezione firstboot% del ks.cfg): hostsvc vim-cmd / datastore / rinominare Datastore1 "$ (hostname-S)-local-storage-1"
Tip # 11
SNMP è un'altra di quelle configurazioni che non può essere configurato e avviato tramite normali servizi come avresti fatto in classico ESX. È possibile apportare le modifiche necessarie al file di configurazione e sarà necessario riavviare l'host per le modifiche abbiano effetto, proprio come configurazioni NTP. Avrete bisogno di editare / etc / vmware / snmpd.xml e aggiungere che alla vostra sezione firstboot . Ecco un esempio di file di snmpd.xml:
Suggerimento # 12
Un utente VMTN ha recentemente pubblicato un problema quando l'applicazione di patch durante firstboot, che non venivano rimossi gli script di init e gli script continuano ad eseguire ad ogni riavvio. Il problema era che il boot.cfg non venivano correttamente aggiornate sotto / VMFS / volumi / Hypervisor {1,2}. Ho fatto alcuni test e ha scoperto che se si è creato un secondo script di personalizzazione e di eseguire il patching come l'ultimo gradino e rilasciato un riavvio, che non si potrebbe incorrere in questo problema. Ecco un piccolo frammento di ciò che il vostro ks.cfg vorrebbe look con 2 init script personalizzati, una configurati 998 e l'altro configurato 9999:
Suggerimento # 13
Ecco un post su Automatizzare Active Directory Domain Join in ESXi Kickstart
Suggerimento # 14
Ecco un post su Automatizzare gestione utente di Active Directory in ESXi Kickstart Come potete vedere, ci sono un bel paio di hack ho dovuto passare attraverso per ottenere un kickstart equivalente costruire per ESXi 4.1 rispetto a ESX classico. Sono sicuro che ci sono altri trucchi, ma questi sono quelli che avevo incontrato. Nel complesso, ESXi 4.1 è notevolmente migliorata in termini di automatizzare l'installazione automatica e la configurazione di ESXi 4.0, ma c'è sicuramente più lavoro che deve essere fatto da VMware prima che gli utenti possono facilmente passare da ESX classico al ESXi.
Tip # 15
Ecco un post su come aggiungere automaticamente ESX (i) ospita vCenter in Kickstart
In aggiunta alla documentazione di VMware che è ancora limitante, qui ci sono strumenti e link aggiuntivi che saranno utili durante la creazione ks.cfg per ESXi 4.1:
  • http://communities.vmware.com/blogs/vmwareinsmb/2010/07/13/esxi-41-scripted-installation-via-pxe-and-kickstart
  • http://www.kendrickcoleman.com/index.php?/Tech-Blog/esxi-41-kickstart-install-wip.html
  • http://labs.vmware.com/flings/vmware-auto-deploy