venerdì 30 maggio 2014

FXI Cotton Candy: la prima recensione

Da tempo ci occupiamo di Mini PC Android. Oggi parliamo di FXI Cotton Candy grazie all’esaustiva recensione fatta dai ragazzi di laptopmag.com. L’azienda norvegese che lo produce ha iniziato in queste settimane la vendita di dispositivi beta per attirare sviluppatori.
Si tratta, come sempre, di un “piccolo computer” in grado di trasformare il vostro televisore (ovviamente dotato di almeno una presa USB e una HDMI) o il vostro monitor in una postazione di lavoro Android (o Linux, come vedremo).
Esteticamente si presenta piuttosto bene. Il nome Cotton Candy è stato scelto ad indicare l’estrema leggerezza, ovvero meno di 30 grammi. Per quanto riguarda le dimensioni, parliamo di 7.62 centimetri di lunghezza, 2,4 cm di larghezza e 1.27 di spessore; Cotton Candy risulta quindi più piccola e più compatta del “best seller” MK802.
Ha un telaio bianco (che sembra quasi ceramica) in plastica leggera e due tappini in gomma a proteggere entrambe le estremità dove sono alloggiate la porta HDMI e quella USB. Il dispositivo in prova sfoggia il logo Cotton Candy ma è bene sapere che non sarà mai venduto al pubblico con il marchio Cotton Candy da FXI, che invece intende darlo in licenza a terze parti.
A livello hardware ci troviamo di fronte ad un ottimo prodotto: CPU Samsung Exynos 4210da 1,2 GHz  CPU, RAM da 1 GB, Wi-Fi, Bluetooth, connettore USB (per essere collegato ad un alimentatore  o al PC per usare il dispositivo in modalità client), porta HDMI, porta microUSB (per il collegamento di periferiche come tastiera e mouse), pulsante di reset per il modulo Bluetooth e slot per schede microSD.Non avendo memoria interna, è necessario inserire una scheda microSD con il SO (il dispositivo viene fornito con una scheda da 8 GB, ma è possibile arrivare fino a 32 GB) perché il sistema si avvii. La scheda microSD in dotazione è vuota e FXI fornisce sul suo sito due immagini ufficiali di SO, una per Android ICS 4.0 e una di Ubuntu 12, entrambi facilmente scaricabili ed utilizzabili seguendo le istruzioni. Va detto che la comunità di sviluppatori sul sito è incredibilmente attiva e hanno già iniziato a circolare immagini di altre distribuzioni Linux come Fedora.
Come accennato, la particolarità del Cotton Candy rispetto alla concorrenza è quella di poter essere inserita in un PC ed eseguire il suo intero ambiente in una finestra del medesimo. A differenza dei programmi di virtualizzazione come VirtualBox o VMWare che usano la connessione di rete e i componenti hardware del computer, il Cotton Candy utilizzerà la sua CPU e la sua connessione a internet col Wi-Fi.
Cotton Candy viene riconosciuto dal PC come una unità di memoria in Esplora Risorse. Basterà un doppio clic sul file batch di Windows per avviare il software client (ancora acerbo, a dire la verità). Tutto questo lo rende una soluzione ideale per l’utilizzo “mobile”. L’unico difetto riscontrato in queste situazioni è che quando il dispositivo è in modalità “host” si surriscalda dopo pochi minuti di utilizzo. Si spera quindi in nuove funzionalità di risparmio energetico negli aggiornamenti software futuri.
Nella più tradizionale modalità HDMI, collegandolo a un televisore o monitor, il prodotto si è invece comportato molto bene. Per alimentare il Cotton Candy, c’è bisogno di una porta USB o un alimentatore in grado di erogare almeno 1 amp (1.000 mAh). L’avvio, sia di Android che Ubuntu, avviene in meno di un minuto. E’ importante e piacevole scoprire che il Cotton Candy supporta la risoluzione 1080p full HD (1920 x 1080) su entrambi i sistemi operativi. Come in quasi tutti i mini PC di questo tipo, non c’è nessun pulsante on/off, quindi l’unico modo per spegnerlo è  scollegarlo dalla fonte di alimentazione oppure installare un’applicazione apposita.
L’utilizzo di Android “liscio” su dispositivi senza touch screen, può essere una sfida. Lacombinazione tastiera/mouse va bene per la navigazione nel SO e nella maggior parte delle applicazioni; scordatevi però di giocare facilmente ad Angry Birds o simili. Il Cotton Candy non viene fornito di accesso al Google Play Store (FXI sta ancora lavorando per ottenere la certificazione ufficiale da parte di Google) quindi bisognerà rivolgersi altrove per scaricare le app. Il sistema viene fornito con accesso root, ma senza la possibilità di utilizzare il comando su (Super User).
Molti giochi e servizi ancora non sono supportati e si bloccano, mentre quelli che funzionano lo fanno alla grande anche a 1080p. Questo probabilmente grazie alla CPU Exynos, in grado di gestire video full HD anche in streaming. Male invece il Wi-Fi e il Bluetooth che sembrano soffrire di una ricezione scadente.
Con Ubuntu le cose si fanno da una parte più semplici (complice una tonnellata di ottime applicazioni gratuite scaricabili dall’Ubuntu Software Center), dall’altro più complesse per via della qualità dell’immagine del SO non proprio ottimizzata. La build di Ubuntu è piuttosto lenta, e si nota una discreta quantità di lag anche nel fare le cose più semplici, come la navigazione attraverso un elenco di applicazioni disponibili o trascinando una finestra. E il Wi-Fi sotto Ubuntu, se possibile, è peggiore che sotto Android.
Una analisi comparativa del Cotton Candy in questa fase ancora “beta” non è facile. Normalmente il dispositivo, con la sua CPU dual-core, la GPU Mali 400 e 1 GB di RAM, sarebbe sufficiente per giocare e vedere video full HD. Tuttavia, Ubuntu è ancora tremendamente lento, mentre Android presenta troppi fastidiosi lag. I benchmark ci mostrano che è molto più veloce rispetto al MK802 ma allo stato attuale è un dato di poca importanza.
In conclusione: abbiamo visto un certo numero di Mini PC e alcune schede a basso costo nel corso dell’anno, ma nessuno di questi compete tecnicamente con il Cotton Candy (vedi solo il fatto di poterlo utilizzare in modalità client). Se verranno e quando corretti i molti bug dei vari SO disponibili, potrebbe non avere rivali e meritarsi le mentite spoglie di un set-top box o di un dispositivo di intrattenimento “mobile”.
Ma al di là di tutto, possiamo dire che con l’avvento di questi dispositivi, stiamo assistendo alla nascita di una nuova piattaforma informatica. E il Cotton Candy sembra un inizio promettente.

martedì 27 maggio 2014

Ho bisogno di licenze aggiuntive per Nested ESXi?

Il tema delle licenze è di solito qualcosa cerco di stare lontano da, perché non ho alcun interesse in essa e di solito è complessa, che finisce per danneggiare il cervello. Detto questo, una domanda che ricevo ogni tanto da parte dei clienti che gestiscono gran numero di casi Nested ESXi nel loro ambiente è se o non hanno bisogno di una licenza aggiuntiva per un'istanza Nested ESXi?
La risposta a questa domanda può essere trovata in un VMware KB 2009916 che è stato pubblicato lo scorso anno, ecco un breve estratto:
I clienti che utilizzano nidificato ESXi / ESX avranno bisogno di ottenere licenze aggiuntive per la nidificato ESXi / ESX. Questo include, ma non è limitato a:
  • VMware ESXi / ESX in esecuzione in VMware Workstation o VMware Fusion
  • VMware ESXi / ESX in esecuzione in VMware ESXi / ESX
  • VMware ESXi / ESX in esecuzione in altre soluzioni di terze parti hypervisor
So che questo potrebbe essere un po 'deludente sentire, ma si dovrebbe ricordare che nidificato Virtualization e in particolare Nested ESXi non è ufficialmente supportato da VMware. Come tale, da un punto EULA di vista, questo è solo visto come un altro esempio di ESXi da distribuire che richiederà una licenza. Per i clienti che hanno un ELA (accordo di licenza Enterprise) con VMware, questo non è un problema, ma per gli altri che non hanno un ELA, qui ci sono un paio di suggerimenti che possono aiutare.
Disclaimer: Le informazioni elencate di seguito sono quelli della mia opinione personale. Per dubbi o chiarimenti riguardanti le licenze, si prega di raggiungere il vostro account di squadra di VMware.
  • Run ESXi in modalità di valutazione - A seconda del caso d'uso, potrebbe essere solo bisogno l'istanza Nested ESXi per un breve periodo di tempo e si può sempre reinstallare utilizzando la valutazione 60 giorni
  • Configurare Nested ESXi con un'unica CPU virtuale - Da ESXi è concesso in licenza in base al socket, è possibile assegnare una singola CPU virtuale con 2 core per ridurre al minimo l'impatto delle licenze. Per i clienti che utilizzano vCloud Director, e non è la più recente versione 5.5 VCD, è possibile importare il Nested ESXi VM attraverso vCenter Server come VCD non supporta per l'assegnazione di base nelle versioni precedenti

venerdì 23 maggio 2014

Ho bisogno di licenze aggiuntive per Nested ESXi?

Il tema delle licenze è di solito qualcosa cerco di stare lontano da, perché non ho alcun interesse in essa e di solito è complessa, che finisce per danneggiare il cervello. Detto questo, una domanda che ricevo ogni tanto da parte dei clienti che gestiscono gran numero di casi Nested ESXi nel loro ambiente è se o non hanno bisogno di una licenza aggiuntiva per un'istanza Nested ESXi?
La risposta a questa domanda può essere trovata in un VMware KB 2009916 che è stato pubblicato lo scorso anno, ecco un breve estratto:
I clienti che utilizzano nidificato ESXi / ESX avranno bisogno di ottenere licenze aggiuntive per la nidificato ESXi / ESX. Questo include, ma non è limitato a:
  • VMware ESXi / ESX in esecuzione in VMware Workstation o VMware Fusion
  • VMware ESXi / ESX in esecuzione in VMware ESXi / ESX
  • VMware ESXi / ESX in esecuzione in altre soluzioni di terze parti hypervisor
So che questo potrebbe essere un po 'deludente sentire, ma si dovrebbe ricordare che nidificato Virtualization e in particolare Nested ESXi non è ufficialmente supportato da VMware. Come tale, da un punto EULA di vista, questo è solo visto come un altro esempio di ESXi da distribuire che richiederà una licenza. Per i clienti che hanno un ELA (accordo di licenza Enterprise) con VMware, questo non è un problema, ma per gli altri che non hanno un ELA, qui ci sono un paio di suggerimenti che possono aiutare.
Disclaimer: Le informazioni elencate di seguito sono quelli della mia opinione personale. Per dubbi o chiarimenti riguardanti le licenze, si prega di raggiungere il vostro account di squadra di VMware.
  • Run ESXi in modalità di valutazione - A seconda del caso d'uso, potrebbe essere solo bisogno l'istanza Nested ESXi per un breve periodo di tempo e si può sempre reinstallare utilizzando la valutazione 60 giorni
  • Configurare Nested ESXi con un'unica CPU virtuale - Da ESXi è concesso in licenza in base al socket, è possibile assegnare una singola CPU virtuale con 2 core per ridurre al minimo l'impatto delle licenze. Per i clienti che utilizzano vCloud Director, e non è la più recente versione 5.5 VCD, è possibile importare il Nested ESXi VM attraverso vCenter Server come VCD non supporta per l'assegnazione di base nelle versioni precedenti
Se ritieni che Nested ESXi dovrebbe essere sostenuta o che ci dovrebbe essere una caratteristica specifica SKU o concesso in licenza per Nested ESXi, assicurarsi di fornire questo feedback al team di account locale con i vostri casi d'uso in modo che possa essere ricondotta alla gestione del prodotto.

lunedì 19 maggio 2014

esxcli Part1 - Che cosa è esxcli?

esxcli è un nuovo CLI (interfaccia a riga di comando) Quadro in vSphere che fornisce un'architettura modulare per i vari componenti chiamati spazi dei nomi in esecuzione in VMkernel. Alcuni di questi spazi dei nomi sono NMP(Native Multipathing Plugin) per il nuovo VMware Pluggable Storage Architecture, corestorage norme di reclamo utilizzati per mascherare alcuni dispositivi a un host, e swiscsi per gestire l'interfaccia iSCSI.
esxcli può essere eseguito all'interno del classico ESX Service Console, la console Busybox non supportato in ESXi o usando la versione telecomando del vCLI di esxcli. Attualmente ci sono 3 spazi dei nomi (NMP, corestorage e swiscsi) con la versione corrente di vSphere e possiamo vedere gli altri introdotte nelle prossime versioni di vSphere. Una cosa importante da notare è che, poiché questi moduli eseguiti all'interno dell'ospite, utilizzando la versione del vCLI di esxcli, sarà necessario autenticarsi all'host primi a vedere quali moduli saranno disponibili per l'accesso. Attualmente, esxcli non è vCenter consapevoli, significa che è necessario connettersi a un ESX specifico o host ESXi quando si esegue un'operazione.
Ecco un esempio di esxcli eseguiti senza la connessione all'host prima:
Ecco un esempio di esxcli essere eseguiti dopo il collegamento all'host:
Quando si richiama il comando esxcli, si può inoltre notare viene generato un esxcli.log. Se il comando viene eseguito correttamente, il registro sarà generalmente vuota, ma se c'è stato un errore si consiglia di dare un'occhiata al esxcli.log se il comando non fornisce alcun output sullo schermo.
Ecco un esempio di utilizzo di un file di configurazione auth e per la sensibilità caso di esxcli, la voce VI_PROTOCOL non riesce con HTTPS vs https:
[Vi-admin @ Scofield ~] $ cat esxcli.log
[Root CRITICAL] Eccezione: il protocollo non supportato 
[root CRITICAL] Traceback (chiamata più recente scorso): 
File "esxcli.py", la linea 387, in _GetStub 
file "/ vmware/esx40-dev/esx40/bora/vim/py/esxcli / Session.py ", la linea 239, in stub 
file "/ vmware/esx40-dev/esx40/bora/vim/py/esxcli/Session.py", la linea 299, in apposito 
Eccezione: il protocollo non supportato
Non c'è un sacco di informazioni a disposizione del pubblico circa esxcli. Da quello che ho capito dopo aver parlato con alcuni ingegneri di VMware, esxcli ha un API, ma non è attualmente esposto al pubblico per il consumo. Non solo c'è una API, ma i fornitori 3rd party o utenti potenzialmente in grado di creare i propri moduli e installarlo utilizzando il formato VIB noto anche come vSphere Installazione Bundle.
Alcuni pacchetti ben noti che sono attualmente distribuiti in formato VIB oggi sono: Cisco Nexus 1000V VEM, HP Insight Manager Agent, EMC PowerPathV / E, driver Xsigo ESX IB e aggiornamenti VMware ESX / ESXi / VMA, per citarne alcuni. Speriamo che in futuro, VMware esporrà la funzionalità API esxcli per l'ecosistema sviluppatore.

venerdì 16 maggio 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 è vuoto 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.
Suggerimento # 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