Se state pianificando un aggiornamento in-place verso vCenter Server 6.0 (mi riferisco alla versione installabile per Windows) allora dovrete leggere molto attentamente le varie informazioni presenti nella pagina vSphere Upgrade Center.
Naturalmente l’aggiornamento non è l’unica opzione. In alternativa è anche possibile creare un nuovo vCenter Server e passare tutto sul nuovo sistema. Anzi… potrebbe essere persino l’occasione per passare al vCenter Server Appliance (e c’è pure un Flings che vi aiuterà a migrare i dati).
Però in alcuni scenari è necessario mantenere il vCenter (ad esempio per il nome DNS) e procedere con un aggiornamento in-place.
Al momento non voglio commentare la procedura di aggiornamento del vCenter Server, sia perché vi sono molte risorse che già spiegano questa procedura. Sia perché la procedura stessa è abbastanza semplice e molto guidata.
L’attenzione maggiore è nel verificare e pianificare bene prima la verifica della compatibilità, la rimozione di plugin non supportati, controllare bene i pre-requisiti (ad esempi quelli sullo spazio su disco!).
Alcune note importanti vi sono però per chi aggiorna un vCenter con database di tipo SQL (Server o Express), dato che vi possono essere alcuni problemi.
Il primo possibile problema riguarda il fatto che il supporto a SQL Server 2005 è stato rimosso, ma anche a livello di compatibilità delle tabelle e database: questi dovranno avere un livello di almeno 100 (corrispondente a SQL 2008). Altrimenti comparirà un messaggio di errore di questo tipo: incompatible Microsoft SQL Server compatibility level SQL Server with compatibility level 2008 (100) or higher.
Attenzione che potreste ricadere in questa sitazione se avere continutato ad aggiornare il vostro vCenter Server e siete partiti proprio da un SQL Server o Express 2005 (o precedente). Questo problema si risolve facilmente da command line con l’istruzione SQL:
ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = 100
Oppure in modo semplice da SQL Management Studio dove è possibile cambiare il livello di compatibilità del database del vCenter Server direttamente dalle opzioni dello stesso(impostate almeno il livello 100):
Il secondo possibile problema può capitare nello scenario dove si utilizza un SQL Server (o SQL Express) locale nella stessa macchina dove sono installati i servizi del vCenter. In questo caso si potrebbe avere un errore di questo tipo: The vCenter Server service is running under the local system account and the vCenter Server DSN is configured to use Windows integrategrathere authentincation This combination is not supported.
Accade se avete scelto di far girare i servizi come SYSTEM (soluzione ragionevole se è tutto locale nella stessa macchina) e se avete creato una connessione ODBC con autenticazione integrata Windows (configurazione di default).
In questo caso bisogna o assegnare un utente di dominio (in teoria dovrebbe andare anche con un utente locale) ai servizi di vCenter Server, con i privilegi giusti, oppure utilizzare (e abilitare se non l’avete fatto) l’autenticazione SQL al posto di quella Windows per la connessione ODBC.
Entrambi gli approcci risolvono il problema, ma ho notato che poi risulta difficile (post aggiornamento) rimettere i servizi in esecuzione come SYSTEM invece di un utente reale.
Per chi utilizza SQL Express deve poi ricordarsi che tutti i dati saranno migrati all’interno del database Postgres embedded (vi viene chiesto anche in che directory esportare temporaneamente i dati). Però SQL Express probabilmente vi servirà ancora per due motivi. Il primo è legato ad Update Manager: se lo installate avrà bisogno di un database SQL Server o SQL Express. Il secondo è legato ad uno strano comportamento post aggiornamento (nel caso che abbiate impostato l’autenticazione SQL). Sembra che il servizio vCenter Server (vpxd) continui a fare riferimento alla vecchia connessione ODBC verso SQL (anche se poi effettivamente non viene più usata). La conferma è anche solo cancellando l’ODBC DSN obsoleto, il servizio vCenter Server non riparte più! Probabilmente questo bug sarà sistemato in una prossima build o semplicemente basterà cancellare a livello di vpxd il riferimento alla vecchia connessione (in teoria è all’interno del registro, ma non ho ancora avuto abbastanza tempo da fare un po’ di prove).