Most viewed posts

Upgrade path to vSphere 5 – The VM part

15 Novembre 2011
No comments
Reading Time: 3 minutes

Come scritto in precendenza, l’aggiornamento delle VM richiede prima l’aggiornamento delle VMware Tools e poi (ma non è strettamente necessario) l’aggiornamento del virtual hardware. Vi sono però delle considerazioni aggiuntive da fare a riguardo.

Tra l’altro, qualche giorno fa mi sono imbattutto in un aggiornmanto da VI 3.5 (tra l’altro solo U1) direttamente a vSphere 5, trovando che, paradossalmente, gli unici problemi si sono avuti nell’aggiornamento delle VM, visto che per vCenter Server e hosts ho utilizzato una reinstallazione completa.

Alcune delle mie osservazioni:

  • Sembrerà banale, ma fare un check delle VM prima di procedere con l’aggiornamento: vericare the tutti i servizi partano dopo un riavvio, che non vi siano errori e che vi sia abbastanza spazio nel disco di sistema per l’aggiornamento delle VMware Tools (purtroppo anche il vSphere 5 manca il monitoraggio dello spazio disco dentro il guest OS).
  • Benché sia l’aggiornamento delle VMware Tools che quello del virtual hardware possono essere orchestrati con VUM, consiglio almeno per le prime VM (una per tipologia) di procedere con un aggiornamento manuale per scoprire gli eventuali problemi.
  • Da GUI l’aggiornamento del virtual hardware è forzato alla versione 8, quindi si tratta di saltare dalla versione 4 (che comunque può essere eseguita su vSphere 5) alla versione 8.
  • L’aggiornamento del virtual hardware determina un riordino delle schede PCI virtuali (ricordiamoci che dalla versione 7 supportano l’hot-add)… la conseguenza è che VM con più di un vNIC possono subire uno scambio tra vNIC.
  • Le nuove VMware Tools sono compatibili con vSphere 4.x, ma con VI 3.x? L’unico problema serio che ho trovato è che in alcuni casi la scheda di rete flexible non funziona più correttamente (continua a attivarsi/disattivarsi), la soluzione, in questi casi, è toglierla ed usare una nuova scheda.
  • L’aggiornamento delle VMware Tools è consigliato (se possibile) farlo in modo interattivo… richiede la disinstallazione delle vecchie e l’installazione delle nuovo.
  • La KB1012259 (VMware KB: msvcp71.dll is removed after uninstalling ESX/ESXi 3.5) è valida anche con vSphere 5, ricordarsi di salvare il file prima di aggiornare le VMware Tools (o recuperarlo dalle vecchie VMware Tools). Attenzione che vari programmi sono affetti da questa libreria (come ad esempio SQL Server 2000).
  • Per le VM Linux ho trovato più veloce aggiornare prima il virtual hardware e poi le VMware Tools (operazione che non richiede riavvi in Linux). Questo vale anche per un aggiornamento da vSphere 4.x.
  • Di View, si è già discusso in precedenza, nel caso il PCoIP non funzioni più dopo un aggiornamento delle VMware Tools, procedere con una riparazione del View Agent.
  • Fatto l’aggiornamento delle VM, poi bisogna anche testarle!
VMware

Upgrade path to vSphere 5 – The vSphere part

14 Novembre 2011
2 comments
Reading Time: 4 minutes

In un processo di upgrade a vSphere, la parte relativa a vSphere è probabilmente la più semplice visto che è del tutto simile ai precenti upgrade, soprattutto nei passi da seguire: prima il vCenter Server (la versione nuova può gestire host nuovi e vecchi, quella vecchia non può gestire host nuovi), poi VUM (che può essere utilizzato per gestire l’aggiornamento degli host, delle VMware Tools e del virtual hardware), poi gli host, quindi le VMware Tools e solo alla fine il VMFS5 dei datastore e il nuovo virtual hardware delle VM.

vCenter Server

L’upgrade del vCenter Server è relativamente facile ed indolore e, se si parte dalla versione 4.1 è possibile usare direttamente l’aggiornamento in-place (dato che i requisiti di vCenter Server 4.1 sono praticamente gli stessi della versione 5.0); unico “problema”, se si usa SQL Express, questo non verrà aggiornato all’ultima versione (ma SQL Express 2005 rimane comunque supportato anche da vCenter Server 5.0).La procedura di aggiornamento in-place viene attivata in modo semplice: basta eseguire una nuova installazione, specificando il DB esistente.

Naturalmente, nel caso di una nuova installazione di vCenter Server (o nel caso dell’utilizzo di vCSA), bisognerà decidere se cercare di migrare i dati (non sempre possibile) o partire da zero con una nuova configurazione e realizzare un nuovo vCenter Server a cui poi collegare gli host esistenti.

Ricordarsi di aggiungere le nuove licenze, sia nel caso di upgrade che di reinstallazione (e ricordarsi anche di mantenere le vecchie licenze nella fase di transitorio). Sulla scelta di dove installare vCenter Server, vedere la pagina relativa a “vCenter Server fisico o virtuale?“.

Nel caso di aggiornamento del vCenter Server, prima procedere consiglio di rimuovere i plugin non necessari, quelli non più disponibili in vSphere 5 (come il Guide Consolidation e il Converter Enterprise) e valutare se quelli rimanenti andranno aggiornati o se posso semplicemente essere reinstallati (ad esempio per VUM può essere più semplice rimuoverlo prima e installarlo poi).

Host ESX/ESXi

L’aggiornamento degli host può essere gestito in diversi modi, ma fondatamente le strade percorribili sono l’aggiornamento  in un host (con VUM o altre strade, ma solo sotto alcune condizioni) oppure la completa reinstallazione degli host (per maggiori informazioni vedere anche le VCP5 study notes).

Per gli host di tipo (legacy) ESX, l’aggiornamento in-place non è possibile se l’host è stato precedentemente aggiornato da una versione 3.x (in questo caso la partizione di boot di default è troppo piccola per ospitare un ESXi 5 completo)… in questi casi l’unica soluzione è la reinstallazione.

Un altro motivo per scegliere la reinstallazione è quello di spostare l’installazione di ESX/ESXi da una posizione ad una nuova o per implementare soluzioni di host provisioning alternative (tipo l’Autodeploy).

Prima di procedere con un aggiornamento, consiglio di rimuovere eventuali plugin e moduli di terze parti (controllando anche eventuali moduli multi-path che potrebbero non essere più compatibili con vSphere 5). Per gestire l’aggiornamento la procedura più semplice è quella di affidarsi a VUM (esattamente come negli aggiornamenti da altre versioni).

Da notare che durante l’aggiornamento si avrà un cluster con host vecchi e nuovi, ma è comunque possibile usare vMotion (ovviamente se sono rispettati i requisiti di vMotion). Riguardo ad HA e DRS, può essere ragionevole disabilitarli durante questa fase. Da notare che finché nel cluster vi sono host “misti” i datastore condivisi dovranno rimanere in versione VMFS3 e il virtual hardware delle VM dovrà rimanere versione 7 (o anche 4). Invece le nuove VMware Tools potranno già essere installate visto che supportate anche sugli host 4.x.

Datastore e VM

Alla fine, quando tutti gli host sono ESXi 5, è possibile procedere all’eventuale aggiornamento dei datastore a VMFS5 (ma è anche pensabile rifare i datastore, se vi è abbastanza spazio libero). L’aggiornamento del datastore può avvenire in modalità “live” con le VM in funzione (vedere anche le VCP5 study notes), questa sicuramente è una novità rispetto all’aggiornamento da VMFS2 a VMFS3.

L’aggiornamento del virtual The virtual hardware può essere pianificato (ma solo dopo l’aggiornamento delle VMware Tools) oppure no… se le nuove funzioni del virtual hardware 8 (come più di 8 vCPU, il supporto 3D, …) non servono, allora si può semplicemente tenere il virtual hardware 7. Da notare che VUM è in grado di orchestrare sia l’aggiornamento delle VMware Tools sia quello del virtual hardware.

Per maggiori informazioni:

Per installare il software di monitoraggio e gestione dell’hardware dei server fisici, fare riferimento alle istruzioni fornite dal vendor. Per i server Dell vedere l’articolo di come installare OMSA.

Ricordarsi inoltre che con vSphere 5 vi sono anche nuove funzioni da tenere in considerare ed eventualmente utilizzare… ad esempio è possibile utilizzare il Syslog Server per gestire i log degli host ESXi.

VMware , ,

VMware vSphere 4.1 Update 2 e View 4.6

11 Novembre 2011
No comments
Reading Time: 2 minutes

Parlando di aggiornamenti di vSphere e View nel precedente post, mi sono ricordato di un possibile scenario di aggiornamento che al momento pare non essere considerato o quanto meno non ho visto una KB a riguardo.

Recentemente è stato rilasciata un aggiornamento minore di vSphere 4.1 (la Update 2, annunciata in un precedente post) che sicuramente molti utilizzatori di vSphere 4.1 applicheranno. Ma se in quella infrastruttura è installato anche View come bisogna comportarsi? Abbiamo visto che i major upgrade possono comprometterne il funzionamento, ma i minor upgrade? Per le normali patch non vi sono problemi, ma per un intero “Update pack”?

La documentazione di View 4.6 si limita a citare una generica “vSphere 4.1 or later”, ma del resto tutta l’area download di View 4.6 è rimasta “congelata” all’ultimo rilascio di View, tanto più che viene proposto il download di vSphere 4.1 U1. In attesa di un refresh dell’area download o almeno della documentazione, il dubbio rimane.

Da quanto sono riuscito a provare, l’aggiornamento all’Update 2 non crea problemi particolari all’ambiente View 4.6 che continuerà a funzionare come prima (nell’ipotesi di fare un in-line upgrade).

L’unico problema che ho notato è che dopo l’aggiornamento delle VMware Tools (sono in versione più aggiornata rispetto alla Update 1), i desktop virtuali si trovano senza protocollo PCoIP funzionante (il sintomo è la schermata nera del desktop che poi si chiude per timeout), non vi sono invece problemi con il protocollo RDP. Una reinstallazione (scegliendo l’opzione “Ripara”) del View Agent 4.6 sistema questo problema.

VMware ,

Upgrade path to vSphere 5 – The View 5 part

10 Novembre 2011
Comments off
Reading Time: 3 minutes

Come scritto in precedenza, vSphere 5 non è compatibile con le versioni di View precedenti alla 5.0. In un piano di upgrade a vSphere 5, un’eventuale infrastruttura View 4.5 o 4.6 va prima aggiornata a View 5.0 (che a sua volta è compatibile con vSphere 4.0 Update 3 o vSphere 4.1 Update 1).

La procedura di aggiornamento (da fare quindi prima di quella di vSphere 5) è descritta bene nella VMware View Upgrade Guide, nella quale la tabella “VMware View Component Compatibility Matrix” descrive molto bene i livelli di compatibilità dei vari prodotti:

Come si nota dalla matrice, il View Connection Server è compatibile anche con versioni vecchie dei vari prodotti, quindi questi server (ed anche i Security Server e Transfer Server) sono i primi canditati per l’upgrade. Se i server erano già dei Windows Server 2008 R2 allora è consigliabile applicare un semplice aggiornamento in-place (verificato i requisiti minimi della memoria).

Notare che l’aggiornamento del Connection Server presenta un potenziale disservizio legato al cambio delle licenze dalla versione 4 alla versione 5 e al fermo e ri-avvio del servizio. Operazione che se ben gestita può richiede una finestra di meno di 15 min. Il Security Server invece non presenta particolari criticità. Per il Transfer Server invece suggerisco di procedere prima con il check-in di tutti i desktop offline (ossia in local mode).

Il passaggio successivo è l’aggiornamento del Composer (durante il quale è meglio fermare il provisioning dei pool). Anche questa operazione è di solito indolore (ed alla peggio vi sono apposite procedure per ripulire il database da pool “corrotti”).

Ricordarsi anche di importare sui Domain Controller i nuovi template per le GPO, il particolare il template PM per la nuova funzionalità di Persona Management (una versione più completa della normale gestione dei profili utente).

Da questo momento si può procedere con l’upgrade di vSphere e nel contempo dei vari View Agent (e anche le varie VMware Tools)  e View Client (questi ultimi possono essere aggiornate anche in un secondo momento, senza pregiudicare le funzionalità di View). Alcune funzioni (ad esempio il Windows 7 3D rendering), disponibili in View 5.0 richiedono però che la VM utilizzi il virtual hardware 8 (e che quindi l’infrastruttura sia stata aggiornata a vSphere 5). Attenzione però che che le VM con virtual hardware 8 NON possono essere poi utilizzate in modalità local mode.

Alcuni utenti hanno riportato problemi ad aggiornare le VMware Tools dopo l’aggiornamento del View Agent, in realtà finora non ho trovato differenze significative nell’ordine con il quale questi due componenti vengono aggiornati.

VMware

Upgrade path to vSphere 5 – The hardware part

9 Novembre 2011
No comments
Reading Time: 3 minutes

Come scritto nel post precedente, la verifica dell’HCL è un passo fondamentale prima di qualunque aggiornamento (e ovviamente anche prima di qualunque implementazione). Uno degli aspetti da considerare è il firmware minimo richiesto da ogni versione di vSphere che sicuramente coinvolge:

  • BIOS dei server fisici: le anomalie di firmware vecchi possono essere decisamente strane (ad esempio su un vecchio IBM mi era capitato che solo una VM a 64 bit alla volta poteva essere eseguita). Il consiglio è aggiornare sempre all’ultima versione.
  • Altri firmware dei server fisici: il BIOS è solo uno dei firmware, alcuni sistemi hanno un firmware specifico per la piastra madre, uno per la scheda di gestione off-band (DRAC, iLOE, …), ma poi bisogna ricordarsi dei firmware dei controller RAID (fondamentali nel caso di storage solo locale) e di storage in generale ed eventuali firmware nelle schede di rete.
  • Firmware degli storage: anche questi spesso sono specificati nelle HCL. Da notare che alcuni funzioni (VAAI, VASA, …) potrebbero richiedere firmware molto recenti.
  • Firmware degli switch: gli switch di rete (inclusi quelli delle reti SAN) non sono esplicitati nell’HCL, ma vanno comunque considerati, visto che l’infrastrutturara è sorretta anche da loro.

Come si aggiornano i vari firmware? Per Storage ed apparati di rete il problema è facilmente risolvibile, visto che il vendor mette a disposizione opportuni strumenti (molto spesso è possibile gestire tutto via web) e le la struttura è opportunamente ridondata è possibile eseguire aggiornamenti “a caldo”.

Ma per i server si possono incontrare diversi problemi: gli aggioramenti sono di solito rilasciati sotto forma di eseguibili per Windows, Linux o per DOS (da usare tipicamente con un floppy di avvio o con una chiavetta USB bootabile)…. Di solito, nulla di specifico per ESXi.

Per i server Dell PowerEdge queste sono le possibili soluzioni per gestire gli aggiornamenti di firmware:

  • Dell Unified Server Configurator (USC): disponibile solo dalla decima generazione dei server, durante la fase POST è attivabile con F10. Per una descrizione vedere questo articolo.
  • Dell Server Update Utility (SUU): DVD bootabile che gestisce gli aggiornamenti del sistema. E’ scaricabile dal sito del supporto tecnico, purtroppo è in formato multi-part e richiede tempo e spazio. HP e IBM hanno soluzioni analoghe.
  • Dell OpenManage IT Assistant: tool gratuito per la gestione centralizzata (vedere relativo articolo). Prevede funzioni di patching, ma non sono mai riuscito a farlo funzionare con host ESXi.
  • Dell Management plugin for VMware vCenter: tool a pagamento per la gestione centralizzata ed integrato con vCenter Server (vedere scheda prodotto).

Nel mio caso, essendo i server PowerEdge 2950 di nona generazione (che comunque sono compatibili con vSphere 5), la comoda funzione di USC non è disponibile. Per fortuna gli host erano degli ESX 4.1 e quindi (con qualche trucchetto) era possibile utilizzare direttamente i file binari per Linux (che invece NON funzionano su un ESXi).

VMware

Percorso di aggiornamento a VMware vSphere 5

8 Novembre 2011
Comments off
Reading Time: 3 minutes

Il percorso di aggiornamento verso vSphere 5 è abbondantemente discusso nella relativa guida (vSphere Upgrade Guide) e in un’apposito white paper (vSphere Upgrade Best Practices).

Sotto determinate condizioni si può applicare un upgrade in place che ha il vantaggio di mantenere tutte (o buona parte) delle impostazioni e, generalmente, richiedere meno tempo: ad esempio il vCenter Server 4.1 può essere aggiornato alla versione 5.0 (di fatto i requisiti sono gli stessi) o una versione di ESXi può essere aggiornata ad ESXi 5.

Ma in molti casi, anche quando magari l’upgrade è possibile, può essere più interessante valutare una completa reinstallazione, con il vantaggio di partire da una soluzione completamente pulita, oltre che minimizzare i disservizi (ad esempio è meno impattante preparare un secondo vCenter Server, configuarlo e poi migrare gli host al nuovo vCenter).

Vi sono comunque degli aspetti generali da tenere in considerazione in qualunque upgrade di vSphere:

  • HCL: la Hardware Compatibility List deve essere sempre controllata prima di ogni aggiornamento (ogni versione ha una sua HCL e non è detto che un prodotto nuovo supporti anche l’hardware supportato da una vecchia versione e viceversa). Inoltre bisogna verificare anche la matrice di compatibilità delle parti software (come ad esempio versioni dei DBMS) nella relativa pagina (VMware Product Interoperability Matrix).
  • Firmware: questo aspetto è legato al punto precedente (ogni versione di vSphere richiede un firmware minimo sia per i server che per gli storage)… di solito si consiglia di aggiornare all’ultima versione di BIOS/firmware (salvo dove diversamente specificato dal vendor, dove ad esempio l’ultima versione di firmware non è consigliata da usare in produzione).
  • ESX: l’upgrade di ESX è possibile solo in certe condizioni (di fatto non deve provenire da un aggiornamento dalle versioni 3.x o precedenti) e non può spostare l’installazione su un dispositivo di tipo flash. In questi casi, di solito, è consigliabile una completa reinstallazione.
  • Driver e moduli: eventuali driver o moduli aggiuntivi di terze parti in ESXi /ESX possono causare problema in fase di upgrade. In questi casi una reinstallazione (o la rimozione degli stessi) può essere risolutiva. Assicurarsi di avere i driver per la nuova versione.
  • Plugin: i vari plugin di vCenter vanno rivisti, sia nella loro parte server-side, sia ovviamente nella parte client side. In molti casi è più semplice rimuovere la componente aggiuntiva prima dell’upgrade per poi installarne la versione nuova (ovviamente in questo modo si perdono tutte le impostazioni).
  • Converter Enterprise e Guided Consolidation: dato che in vSphere 5 non esistono più, questi vanno rimossi prima di aggiornare il vCenter Server.
  • VDR: può avere alcuni problemi in fase di aggiornamento e soprattutto in fase di aggiornamento dei catalog delle destinazioni. Valutare se partire direttamente con un nuovo VDR appliance con destinazioni nuove.
  • View: le versioni View 4.x non sono compatibili con vSphere 5. Va quindi gestito in modo opportuno, come anche spiegato nella sua guida di installazione.
  • SRM: stesso discorso di View… SRM 4.x non è compatibile con vSphere 5.

Nei prossimi post analizzeremo i passi per l’aggiornamento di un’infrastruttura così composta:

  • host ESX 4.1 con Dell PowerEdge 2950 III
  • vCenter Server 4.1 (in a VM)
  • VMware View 4.6
  • iSCSI Storage con Dell Equallogic PS5000XV

Passi per l’aggiornamento:

VMware , ,

VMTN Subscription

7 Novembre 2011
No comments
Reading Time: 2 minutes

Vorrei segnalare l’iniziativa promossa da Mike Laverick con l’obiettivo di ripristinare la “VMTN Subscription”:

I would like to see VMware re-instate the “VMTN Subscription”. You might ask, what the hell is that? That would be fair enough because it was withdrawn many years ago, and never re-instated by VMware.

Ma in cosa consiste la “VMTN Subscription“? Per fare un paragone potremmo dire che era simile alle subscription Microsoft MSDN o TechNet, ossia un modo per ottenere, per un anno, accesso a tutti i prodotti (o buona parte degli stessi) con tutte le funzionalità.

A quale scopo? Ovviamente per studiare ed imparare, ma anche per realizzare laboratori o ambienti di test. Chiaramente questo oggi è comunque possibile con le versioni trial (che ai tempi della VMTN Subscription erano spesso carenti o mancanti), ma purtroppo è limitato ad appena 60 giorni. Per chi lavora presso partner VMware vi è anche l’opzione di usare le licenze per uso interno (NFR), ma per chi è freelance (ad esempio)? Al momento l’unica opzione è data dalle versioni trial, visto che la  VMTN Subscription è stata interrottra nel 2007.

In realtà, qualche segnale interessante c’è stato, come ad esempio l’annuncio dei VMware Labs (forse dal 2012) o i benefit che vengono dati ai vExpert (in alcuni casi si è riusciti a fornire accesso alle versioni beta dei prodotti).

Secondo me, potrebbe essere interessante re-introdurre la VMTN Subscription, ma in una nuova forma che includa non solo l’accesso ai prodotti, ma possibilmente anche l’accesso alle beta degli stessi (almeno di alcuni e se non è possibile alla beta, almeno alle versioni RTM (come del resto già avviene nei programmi Microsoft e non solo), e magari anche ad una buona documentazione e a dei buoni corsi (come ad esempio alcuni della Partner University).

Inoltre, preferirei che questa subscription non venga usata solo per “fare cassa”, ma sia offerta come beneficio (senza costi aggiunti) a tutti quei programmi nei quali le persone hanno investito tempo e/o denaro, come ad esempio i vExpert, il VMUG Advantage package, le certificazioni VCAP o VCDX, …

Per maggiori informazioni:

Generale, VMware none
© 2025-2011 vInfrastructure Blog | Disclaimer & Copyright