Objective 2.1 – Configure vNetwork Standard Switches

Vedere anche questi post: Objective 2.1 – Configure vNetwork Standard Switches e Objective 2.1 – Configure vNetwork Standard Switches e Objective 2.1 – Configure vNetwork Standard Switches.

Identify vNetwork Standard Switch capabilities (same as vSphere 4.x)

Per i concetti base di virtual networking vedere VMware Virtual Networking Concepts e VMware Virtual Networking.

Create/Delete a vNetwork Standard Switch (similar as vSphere 4.x)

Vedere la vSphere Networking Guide (nella sezione dei vSS). Da notare che per il VCP5 non è richiesta una conoscenza dettagliata della CLI…

Rispetto alle precedenti versioni è possibile modificare tramite vSphere Client (prima solo tramite command line) le impostazioni di MTU per i vSwitch (ad esempio per abilitare i Jumbo Frame).

Add/Configure/Remove vmnics on a vNetwork Standard Switch (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 16 e 17). Ogni NIC dell’host agisce come un uplink di per un vSwitch.

Configure vmkernel ports for network services (similar as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 14). I port group di tipo VMkernel possono essere utilizzati per:

  • Management (il portgroup deve avere l’ozione “Management”).
  • vMotion (il portgroup deve avere l’opzione “vMotion”).
  • Management (il portgroup deve avere l’opzione “fault tolerance logging”).
  • IP storage, come iSCSI (nel caso software initiator) o NFS.

Rispetto alle precedenti versioni è possibile modificare tramite vSphere Client (prima solo tramite command line) le impostazioni di MTU per i vmkernel (ad esempio per abilitare i Jumbo Frame).

Add/Edit/Remove port groups on a vNetwork Standard Switch (same as vSphere 4.x)

Vedere la vSphere Networking Guide (pag. 12).

Determine use case for a vNetwork Standard Switch (same as vSphere 4.x)

Sia gli switch standard (vSS) che quelli distribuiti (vDS) possono convivere. Ma i vDS offrono maggiori funzionalità rispetto ai vSS. D’altro canto i vDS richiedono una licenza disponibile solo con l’edizione Enterprise+, rendendo quindi i vSS una scelta obbligatoria per tutte le altre edizioni.

Per ambienti piccoli (con un numero ridotto di host), i vSS sono decisamente più semplici da configurare e gestire: tutto può essere controllato a livello degli host (sotto Configuration-> Networking).

vStorage API

Introdotte per la prima volta in vSphere 4.0, le vStorage API sono funzioni specifiche che permettono una maggiore integrazione con funzioni esterne di storage evoluti. Da notare che esistono anche altri moduli di integrazione che rientrano nel PSA framework. Per maggiori informazioni sulle novità nello storage vedere (in inglese):

vSphere Storage API – Storage Awareness (VASA)

Questo nuovo set di API, introdotto in vSphere 5.0, permette a VMware vCenter Server di individuare specifiche funzionalità e caratteristiche dello storage e delle LUNs/datastore. In questo modo sarà possibile capire il tipo di tecnologia dei dischi (o il livello di prestazioni offerto), oppure sarà possibile semplificare il processo di troubleshooting. Le storage capability, come il livello del RAID, il tipo di provisioning (thin o thick), lo stato della replica e molti altri, divengono visibili in vCenter Server tramite il descrittore “system-defined capabilities”.

Per altre informazioni (in inglese) vedere: Overview vSphere Storage API for Storage Awareness (VASA) e A Deeper Look at VASA.

continue reading…

Progettare in modo corretto la disponibilità del vCenter Server può essere necessario in molti casi, ma può anche divenire critico in ambienti grossi o dove vi sono molti servizi che dipendono da esso. In ambienti piccoli di solito non è in grosso problema e la criticità è relativamente bassa… questo perché molte funzioni possono funzionare senza vCenter Server (per una lista delle dipendenze vedere  vCenter Server: fisico o virtuale?).

Esistono varie soluzioni per incrementare la disponibilità del vCenter Server:

  • Implementare il vCenter Server in virtuale e usare VMware HA.
  • Utilizzare il prodotto di VMware vCenter Server Heartbeat.
  • Utilizzare una soluzione di clustering come MSCS (opzione non più supportata a partire da vSphere 4.x).
  • Utilizzare VMware FT (opzione non supportata).

Per maggiori informazioni vedere: http://kb.vmware.com/kb/1024051 – Supported vCenter Server high availability options. Inoltre è disponibile un post recente (settembre 2012), su Yellow Bricks (Protecting vCenter Server – HA or Heartbeat?).

VMware HA

Per informazioni sulla tecnologia vedere la pagina ufficiale di VMware HA. Ovviamente questa soluzione è utilizzabile solo se il vCenter Server è in una macchina virtuale e se si dispone della licenza di VMware HA!

Bisogna ricordarsi che VMware HA richiede il vCenter Server solo per la fase iniziale di installazione e configurazione; poi lavora sugli host in modo distribuito senza più la dipendenza da vCenter Server. Per questa ragione VMware HA può gestire anche il riavvio della VM del vCenter Server (nel caso di un problema all’host)… con un disservizio totale di solito di pochi minuti.

Quindi per realtà medio/piccole la soluzione VMware HA può essere quella più semplice, valida ed economica (la licenza è inclusa in tutte le edizioni tranne che la Essential). Al fine di mantenere semplice la configurazione è possibile includere nella stessa VM anche il DB necessario al vCenter, altrimenti si rende necessario trovare una soluzione di HA per il DB stesso..

vCenter Server Heartbeat

Per informazioni sul prodotto vedere il sito ufficiale: http://www.vmware.com/products/vcenter-server-heartbeat/

In questo caso il vCenter Server (primary instance) può essere sia in virtuale che in fisico. La seconda istanza (secondary) invece deve essere in virtuale! Questo prodotto è anche in grado di gestire l’alta disponibilità del database (nel caso sia di tipo SQL Server).

Vedere anche: VMware to tackle vCenter availability with new Server Heartbeat.

MSCS o Failover Cluster

Soluzione non più supportata!

Vedere: http://www.vmware.com/pdf/VC_MSCS.pdf e Reference Implementation: Clustering VirtualCenter 2.5 Using Microsoft Cluster Services.

In questo caso il vCenter Server è una risorsa di un cluster applicativo ed i nodi del cluster possono essere virtuali, fisico o fisico/virtuale. Ovviamente per implementare un cluster Microsoft è richiesta una versione di Windows Server Enterprise o Datacenter.

Da notare che vCenter Server 2.5 è supportato solo su sistemi Windows Server 2003 o Windows Server 2003 R2. Mentre vCenter Server 4.0 è supported also on Windows Server 2008. E vCenter Server 4.1 o 5 richiede un sistema a 64 bit (e supportano anche Windows Server 2008 R2).

Una soluzoine simile è quella di utilizzare altre tecnologie di cluster applicativo, come ad esempio Veritas Cluster: http://searchservervirtualization.techtarget.com/news/article/0,289142,sid94_gci1341780,00.html (ma comunque la soluzione non è supportata).

Note: vCenter Server 4.x e 5 non sono più supportati con soluzioni di cluster di terze parti (rispetto a VMware), come ad esempio Microsoft Clustering Service and Veritas Cluster Services.

VMware FT?

Soluzione non supportata!

Ci si potrebbe chiedere perché non usare VMware FT per aumentare la disponibilità di un vCenter Server virtuale? Semplicemente perché il requisito minimo di processore di vCenter Server 4.0 è di almeno 2 vCPU (e potenzialmente di più al crescere dell’infrastruttura da gestire e se il DB è locale).

Come è noto il limite della versione attuale di VMware FT (anche in vSphere 5.0) è di gestire VM ciascuna con solo 1 vCPU. Quindi i si configura un vCenter Server con una sola vCPU (per ambienti piccoli funziona, ma non sarebbe comunque supportato) o non si usa VMware FT.

Per informazioni sulla tecnologia vedere la pagina ufficiale di VMware FT

Per le varie soluzioni utilizzabili per incrementare la disponibilità del vCenter Server vedere anche questa pagina.

Fin dalla versione VI 3.x il vCenter Server poteva essere implementato su server fisico o macchina virtuale (entrambe le soluzioni sono supportate da VMware).

In questa pagina analizziamo i pro e contro di una soluzione rispetto all’altra.

Nota: VMware ha rimosso il concetto vRAM Entitlements, quindi le informazioni di questo post non sono più rilevanti!

Introdotta durante il lancio di vSphere 5, questa novità nella licenza di vSphere (in particolare degli host) è stata rivisitata e migliorata per minimizzare eventuali impatti negativi (il primo a “spoilerare” la possibile notizia è stato Gabrie van Zanten). Non è cambiato il principio, ma i valori e come vengono calcolati. Ecco le novità principali:

  • aumentati i quantitativi di vRAM per tutte le licenze, raddoppiati quelli per le licenze Enterprise e Enterprise Plus;
  • introdotta una soglia massima al quantitativo di vRAM conteggiato per una singola VM (96 GB) così che nessuna VM possa costare più di una licenza Enterprise plus;
  • introdotto un nuovo modello di conteggio, basato sulla media annuale, che non penalizzi gli usi elevati di vRAM per brevi periodi (tipici di ambienti di test e sviluppo ad esempio);
  • aumentato il quantitativo di vRAM della versione free, che era diventata di fatto quasi inutilizzabile: si passa da 8 GB a 32 GB con la limitazione che 32GB sono anche il limite massimo di RAM fisica per il server.
vSphere edition vRAM entitlement precente Nuovo vRAM entitlement
vSphere Desktop Unlimited Unlimited
vSphere Enterprise+ 48 GB 96 GB
vSphere Enterprise 32 GB 64 GB
vSphere Standard 24 GB 32 GB
vSphere Essentials+ 24 GB 32 GB
vSphere Essentials 24 GB 32 GB
Free vSphere Hypervisor 8 GB 32 GB[*]

[*] limite di RAM fisica per ogni server fisico

Vedere anche i post in italiano su:

In inglese vedere:

Objective 1.5 – Identify vSphere Architecture and Solutions Knowledge

Esiste anche questi post simili: Objective 1.5 – Identify vSphere Architecture and Solutions e Objective 1.5 – Identify vSphere Architecture and Solutions.

Identify available vSphere editions and features (some changes from vSphere 4.x)

Vedere sul sito VMware le comparazioni tra i diversi prodotti: Compare vSphere 5.0 Kits e Compare vSphere 5.0 Editions.

Explain ESXi and vCenter Server architectures (similar as vSphere 4.x)

Vedere la guida VMware Sphere Basic, il post Objective 0.1 – VMware Products e anche il VMware Web Site.

Explain Private/Public/Hybrid cloud concepts

Vedere il post precedente: Objective 0.2 – Cloud Concepts.

Determine appropriate vSphere edition based on customer requirements (some changes from vSphere 4.x)

Questa scelta dipende da numerosi fattori, non solo i requisiti del cliente, ma anche i vari vincoli e assunzioni. Il prezzo e la vRAM entintment possono essere un fattore, per maggiori informazioni vedere vSphere 5.0 Licensing, Pricing and Packaging Whitepaper.

Di solito i bundle di tipo Essential coprono le esigenze del segmento SMB (o PMI), la versione Standard può rappresentare un upgrade in ottica di scalabilità del bundle Essential+ bundle, la versione Enterprise può essere la più adeguata in molti casi (da notare che la versione Advanced non è più disponibile) e la versione Enterprise+ è solo per chi necessita di funzioni specifiche di alto livello (come DVS, Auto Deploy, SDRS, SIOC, NIOC, …).

Objective 1.4 –Secure vCenter Server and ESXi

Molti riferimenti sono contenuti nella vSphere Security Guide, ma rimangono tutt’ora validi anche i riferimenti contenuti nel vecchio documento (ancora riferito al VI 3.x) Managing VMware VirtualCenter Roles and Permissions.

Vedere anche (in inglese): Objective 1.4 – Secure vCenter Server and ESXi e Objective 1.4 –Secure vCenter Server and ESXi.

Identify common vCenter Server privileges and roles (similar as vSphere 4.x)

Per l’elenco completo vedere la vSphere Security Guide (pag. 59). I ruoli disponibili sia in ESXi che in vCenter Server sono:

  • No Access: non è possibile vedere l’oggetto. Eventuali tab nel vSphere Client associati a questo oggetto appariranno senza contenuto. Tipicamente viene utilizzato per revocare permessi ad un oggetto figlio che altrimenti sarebbero propagati da un oggetto padre.
  • Read Only: è possibile vedere solo lo stato e i dettagli dell’oggetto. Tutti i tab del vSphere Client associati sono visibili, eccetto la Console tab. Non è possibile alcuna azione tramite menu e toolbar.
  • Administrator: Tutti i privegi su un particolare oggetto.  Notare che gli utenti che sono nel gruppo the Active Directory ESX Admins sono automenticamente assegnati al ruolo Administrator.

Describe how permissions are applied and inherited in vCenter Server (same as vSphere 4.x)

Vedere la vSphere Security Guide (pag. 48 e anche pag. 51 per alcuni esempi).

Quando un permesso viene assegnato ad un oggetto, è possibile scegliere se dovrà essere propagato nella gerarchia sottostante. La propagazione non è globale e universale, ma per ogni permesso.  I permessi definiti in un oggetto figlio hanno sempre la precedenza su quelli che sono propagati dal padre.

Notare che nelle versioni precedenti di vCenter Server, i datastore e le network ereditavano i permessi dal datacenter. In vCenter Server 5.0, questi hanno i loro set di privilegi. Nel caso di un upgrade, potrebbe essere necessario sistemare manualmente questi privilegi, in base all’accesso richiesto. Per maggiori informazioni vedere la vSphere Upgrade Guide (pag. 61).

Configure and administer the ESXi firewall (new in vSphere 5.x)

Vedere la pagina: What’s new in vSphere 5: ESXi firewall.

Enable/Configure/Disable services in the ESXi firewall (new in vSphere 5.x)

Vedere la pagina: What’s new in vSphere 5: ESXi firewall.

Enable Lockdown Mode (same as vSphere 4.x)

Vedere il sito web The New Lockdown Mode in ESXi 4.1 e la vSphere Security Guide (pag. 81).

Da notare che il lockdown mode non si applica nel caso di un accesso a root in SSH con autenticazione crittografica (tramite authorized keys). Inoltre l’utente root potrà comunque accedere all’host tramite la direct console (anche con il lockdown mode abilitato).

Configure network security policies (same as vSphere 4.x)

Vedere : VMware Virtual Networking Concepts e la vSphere Security Guide (pag. 25).

I virtual switch (ma anche i portgroup) hanno la possibilità di applicare policy di sicurezza a livello 2. Vi sono tre tipi di policy:

  • Promiscuous mode is disabled by default for all virtual machines. This prevents them from seeing unicast traffic to other nodes on the network.
  • MAC address change lockdown prevents virtual machines from changing their own unicast addresses. This also prevents them from seeing unicast traffic to other nodes on the network, blocking a potential security vulnerability that is similar to but narrower than promiscuous mode.
  • Forged transmit blocking, when you enable it, prevents virtual machines from sending traffic that appears to come from nodes on the network other than themselves

Per l’uso delle VLAN, in ambito di sicurezza delle reti, vedere la vSphere Security Guide (pag. 20).

View/Sort/Export user and group lists (same as vSphere 4.x)

Vedere la vSphere Security Guide (pag. 45). Notare che esistono sia utenti/gruppi locali (sia nel caso di ESXi che nel caso di vCenter Server) che utenti/gruppi centralizzati (attraverso servizi di directory come Microsoft AD).

Add/Modify/Remove permissions for users and groups on vCenter Server inventory objects (same as vSphere 4.x)

Vedere la vSphere Security Guide (pag. 53) e il sito http://www.vmwarehub.com/Permissions.html.

Create/Clone/Edit vCenter Server Roles (same as vSphere 4.x)

Vedere la vSphere Security Guide (pag. 61). Da notare che quando si rimuove un ruolo assegnato ad un utente o gruppo è possibile scegliere se togliere il ruolo (remove role assignments) o sostituirlo con un altro (reassign affected user to).

Add an ESXi Host to a directory service (same as vSphere 4.1)

In vSphere 5 vi sono due diversi modi per utilizzare l’autententicazione Active Directory negli host ESXi::

  • Aggiungere l’host come “member server” di un Active Directory (come in ESXi 4.1): vedere la vSphere Security Guide (pag. 63).
  • Utilizzare la nuova funzione vSphere Authentication Proxy service (CAM service): vedere la vSphere Security Guide (pag. 65).

Apply permissions to ESXi Hosts using Host Profiles (same as vSphere 4.x)

Vedere Use Host Profiles to Apply Permissions to Hosts (per host registrati in AD) e la guida vSphere Security Guide (pag. 67 per l’uso con vSphere Authentication Proxy).

Determine the appropriate set of privileges for common tasks in vCenter Server (similar as vSphere 4.x)

Vedere la vSphere Security Guide, ma anche in ogni singola guida, di volta in volta, vengono specificati i privilegi richiesti.

Dopo il grande successo del primo evento, sono finalmente disponibili le prime informazioni sul prossimo evento del VMUG italiano. Il formato sarà molto simile a quello già apprezzato nel primo evento con numerosi interventi al mattino, incentrati in modo particolare su vSphere 5, e una interessantissima tavola rotonda pomeridiana sulle soluzioni di backup per VMware. Pranzo e pause ricreative offerte dagli sponsors.

  • Quando: 5 Ottobre 2011, ore 8.00 – 17.30
  • Dove: NH Milanofiori – Strada 2a, Milanofiori – Loc. Assago – MI
  • Tematiche: vSphere5 / Tavola rotonda sulle soluzioni di Backup per VMware
  • Come partecipare: iscrivetevi con questa form.

Con vSphere 5, per la prima, fa la sua comparsa in ESXi un firewall integrato, andando quindi a colmare un’altra differenza tra ESXi e ESX. Pur mantenendo una gestione (almeno nella GUI) simile a quella del vecchio ESX, questo “personal” firewall è completamente nuovo con alcune caratteristiche peculiari.

Per maggiori informazioni: http://vinfrastructure.it/vdesign/esxi-5-firewall/

Sul sito di VMware sono state pubblicate le nuove versioni dei blueprint degli esami VCP, sia per VCP4 che per il VCP5:

Riguardo il documento del VCP5, come si nota dal titolo, è ancora riferito alla versione beta dell’esame e soprattutto non apporta alcuna modifica nella sezione degli obiettivi e argomenti dell’esame. La versione con appunti e note è in via di sviluppo.

Objective 1.3 – Plan and Perform Upgrades of vCenter Server and VMware ESXi

Vedere anche questo post: Objective 1.3 – Plan and Perform Upgrades of vCenter Server and VMware ESXi e Objective 1.3 – Plan and Perform Upgrades of vCenter Server and VMware ESXi.

Identify upgrade requirements for ESXi hosts (similar as vSphere 4.x)

Per i requisiti vedere: vSphere Upgrade Guide (pag. 11) e vSphere Upgrade Guide (pag. 69).

I requisti di sistema per l’aggiornamento a ESXi 5 sono gli stessi di una nuova installazione: processore a 64 bit, una o più schede di rete supportate, 2098 MB RAM (notare che è leggermente di più di 2 GB), storage supportato, … Per l’aggiornamento poi vi sono ulteriori requisiti che dipendono dal tipo di host sorgente.

Da notare che nella documentazione di parla spesso di upgrade e migration come sinonimi, ma in realtà l’aggiornamento da ESXi 4.x a ESXi 5 è un upgrade mentre quello da ESX 4.x a ESXi 5 è una migrazione. L’aggiornamento si può realizzare in modalità automatica (con VUM o tramite scripting) o in modalità interattiva (avviando l’installazione di ESXi da CD, DVD, o USB).

Ricordarsi di studiare anche quali file sono migrati e mantenuti in un processo di migrazione da ESX 4.x to a ESXi 5 (di solito non sono mantenuti quelli che non hanno senso in ESXi).

Identify steps required to upgrade a vSphere implementation (similar as vSphere 4.1)

Vedere tutta la vSphere Upgrade Guide. Fondamentalmente i passi da compiere (dopo la verifica dei requisiti) sono:

  • Aggiornare il vCenter Server (l’upgrade dalla versione vCenter Server 4.1 è possibile, eccetto il caso in cui è installato su Windows XP) o installare un nuovo vCenter Server 5 (necessario per gestire host in versione 5). L’unico downtime di questa fase riguarda il vCenter Server (e ovviamente i servizi che dipendono da esso).
  • Opzionalmente, aggiornare o installare VUM (VMware Update Manager) che permette di gestire l’upgrade/migration degli host.
  • Aggiornare o reinstallare gli host (vMotion può funzionare tra host nuovi e vecchi)… non vi sono downtime, se si dispone di vMotion, di più di un host e di sufficienti risorse.
  • Aggiornare i VMware Tools in tutte le VMs (notare che i nuovi Tools funzionano anche su VM che girano su vSphere 4.x)… questo passo non è strettamente richiesto, ma altamente consigliato. Per le macchine virtuali Windows è previsto un downtime (dopo l’upgrade delle VMware Tools è necessario un riavvio).
  • Aggiornare il VMFS (può essere svolto a caldo con le VM in esecuzione e senza downtime)… in realtà non è strettamente richiesto, ma è altamente consigliato… notare che i vecchi host non possono leggere il VMFS5 e che comunque i nuovi host possono lavorare anche il VMFS3.
  • Aggiornare il virtual hardware alla v8 (ma ESXi 5 può lavorare anche con VM in formato v7 e v4 )… passaggio consigliato. Vi è un downtime per ogni VM (la VM deve essere spenta per fare l’upgrade).

Notare che VUM può orchestrare sia gli aggiornamenti degli host che quelli delle VMware Tools che del virtual hardware.

Upgrade a vNetwork Distributed Switch (similar as vSphere 4.1)

Un vSphere DVS (Distributed Virtual Switch) versione 4.0 o 4.1 può essere aggiornato all’ultima versione  (5.0), attivando nuove funzioni del networking di vSphere 5.

Per l’aggiornamento del DVS vedere la vSphere Networking Guide (pag. 24).  Tramite il vSphere Client selezionare la vista Networking inventory. Selezionare il DVS nell’inventario e nel tab Summary, vicino a Version, selezionare Upgrade.

Upgrade from VMFS3 to VMFS5 (new in vSphere 5.x)

vSphere 5 permette un percorso di aggiornamento da VMFS3 a VMFS5 senza downtime. L’upgrade è un’operazione online e non-distruttiva che garantisce la non interruzione delle VM. Ma di datastore aggiornati possono avere un impatto sulle operazioni SDRS, in particolare le migrazioni delle VM.

Nell’upgrade da VMFS3 a VMFS5, il block size del VMFS3 sarà mantenuto, mentre sui nuovi datastore VMFS5 il datastore sarà sempre di 1MB.

Negli host aggiornati, il VMFS non viene automaticamente aggiornato. ESXi 5 è compatibile con i datastore VMFS3. Per maggiori informazioni sul VMFS5 vedere la vSphere Storage Guide (pag. 206).

Notare che i nuovi ESXi utilizzano uno schema della partizioni completamente differente (GPT invece che il vecchio MBR), questo anche per gestire dischi e LUN più grandi di 2 TB.

Per maggiori informazioni vedere anche: http://www.boche.net/blog/index.php/2011/07/21/vmfs-5-vmfs-3-whats-the-deal/

Upgrade VMware Tools (same as vSphere 4.x)

Vedere la vSphere Upgrade Guide (pag. 138). Questa operazione può essere eseguita manualmente (dal vSphere Client) o tramite VUM. Da notare:

  • La nuova versione delle VMware Tools (di vSphere 5.0) è supportata su VM in vSphere 4.x e 5.0. Quindi anche per host “vecchi” (ma solo alla versione 4.x).
  • In vSphere 5.0 si possono utilizzare VM con VMware Tools della versione 4.x e/o 5.x. Quindi non è strettamente necessario aggiornare le VMware Tools (o quanto meno non subito).

Upgrade Virtual Machine hardware (same as vSphere 4.x)

Vedere la vSphere Upgrade Guide (pag. 154). Operazione che può essere applicata solo a VM spenta. Da notare che alcune nuove funzioni (come ad esempio più di 8 vCPU) richiedono il nuovo virtual hardware (v8). ESXi 5 può creare, eseguire e modificare VM con v8 e v7 VMs, inoltre può eseguire e modificare VM con v4.

La Paravirtualization (VMI) non è più supportata in ESXi 5.0. Quindi non è possibile accendere una VM VMI-enabled migrata da host 3.x o 4.x verso un host ESXi 5.

Upgrade an ESXi Host using vCenter Update Manager (similar as vSphere 4.x)

Vedere la vSphere Upgrade Guide (pag. 92). Tramite VUM è possibile eseguire un upgrade “orchestrato” di host 4.x tramite una singola upgrade baseline. Per creare una baseline è sufficiente importare nel Update Manager repository la ISO dell’installazione di ESXi 5.

Determine whether an in-place upgrade is appropriate in a given upgrade scenario (similar as vSphere 4.x)

Alcuni percorsi di aggiornamento non sono supportati e quindi potrebbero essere rimpiazzati con una reinstallazione… ad esempio:

  • ESX/ESXi 3.x host: O si aggiornano alla versione 4.x (con qualche possibile problema per ESX) oppure si reinstallano.
    ESX 4.x host che sono stati aggiornati da ESX 3.x con un layout di partizioni non compatibile con ESXi 5.0: in questo caso bisogna reinstallare.
  • Non è possibile utilizzare l’Auto Deploy per aggiornare o migrare alla versione ESXi 5.0, perché le i vecchi host utilizzano un deploy tradizionale e non compatibile con questa nuova funzionalità.
  • Nel caso sia necessario cambiare la posizione dell’installazione (ad esempio da dischi locali a SD Flash o viceversa) è consigliabile una reinstallazione.
© 2017 © 2013 vInfrastructure Blog | Hosted by Assyrus