NoLabNoPartY.com » vcenter

In VMware vCenter il servizio CollectorServerHost.exe utilizza il 100% della CPU

P@olo — Mon, 05 Dec 2011 06:00:00 +0000

Il sistema di monitoraggio della rete segnalava un utilizzo molto elevato della CPU nel server VMware VirtualCenter richiedendo un certo tempo per effettuare le varie operazioni.

Tramite il Windows Task Manager si nota che il servizio CollectorServerHost.exe utilizza quasi il 100% della CPU rendendo la risposta del server molto lenta. Questo servizio fa parte della VMware Guided Consolidation, un’opzione inclusa nell’installazione di vCenter.

1. SOLUZIONE
Se questa feature non è richiesta nel business svolto e senza dover rimuovere il servizio che potrebbe ritornare utile un domani, il sistema viene configurato per disabilitare questa opzione. Tramite Notepad, editare il file vpxd.cfg situato in Windows 2008 R2 in C:\ProgramData\VMware\VMware VirtualCenter\ (in Windows 2003 si trova in %ALLUSERPROFILE%\Application Data\VMware\VMware VirtualCenter\).

Identificare la sezione e aggiungere le istruzioni qui riportate e salvare il file.

true

Da Start –> Administrative Tools –> Services, riavviare il servizio VMware VirtualCenter Server.

Il servizio viene riavviato insieme al servizio collegato VMware VirtualCenter Management Webservices.

Tramite Windows Task Manager verificare nuovamente il carico della CPU.

Dopo la modifica i valori di utilizzo della CPU rientrano nella normalità risolvendo così il problema. Per riabilitare il servizio è sufficiente rimuovere le righe precedentemente inserite nel file vpxd.cfg e riavviare il servizio VMware VirtualCenter Server.

Hai già letto questi articoli?

Errore editando i setting del template in vCenter Server 4.1 “PropertyCollector.RetrieveContents”

P@olo — Mon, 04 Jul 2011 05:00:00 +0000

Utilizzando vCenter Server può capitare un problema nella fase di editing dei template che potrebbe creare un po’ di panico nel reparto IT impattando sui tempi operativi dei servizi della struttura informatica.

Anche i template, che non sono altro che virtual machine, devono essere periodicamente aggiornati in modo da tenere tutto il sistema up-to-date. Se vengono utilizzati template mai aggiornati, è necessario investire tempo per aggiornare il sistema prima di poter essere operativo e pronto per essere messo in produzione.

1. ERRORE
Il problema si verifica quando si cerca di editare in vCenter Server i settings del template di una particolare virtual machine.

Convertire il template in virtual machine per permettere l’editing, selezionare il template, click col tasto destro del mouse e selezionare la voce Edit Settings.

Il sistema visualizza un messaggio di errore.

Il problema viene risolto effettuando l’operazione di rimozione/aggiunta del template dall’Inventory.

2. PROCEDURA
Selezionare da vCenter Server il template da editare, click col tasto destro del mouse e selezionare la voce Remove from Inventory.

Compare la finestra di Warning, click su Yes per procedere.

Il template viene rimosso da vCenter e non è più presente nella lista.

A questo punto bisogna aggiungere nuovamente il template all’Inventory per poterlo visualizzare. A seconda della configurazione dello storage utilizzato dall’infrastruttura VMware, identificare lun o partizione in cui è salvato il template da ripristinare, selezionarlo, cliccare col tasto destro del mouse selezionare la voce Browse Datastore.

Nella lista di virtual machine e template contenuti nell’area di storage selezionata, accedere nella directory del template da ripristinare ed identificare il file con estensione .vmx. Click col tasto destro del mouse e selezionare la voce Add to Inventory.

La procedura di aggiunta di una vm all’Inventory prevede la configurazione di alcuni parametri. Specificare in quale datacenter, se più di uno, assegnare il template.

Assegnare il template al cluster dell’infrastruttura VMware.

Specificare l’eventuale resource pool.

L’ultima videata presenta il riepilogo delle impostazioni effettuate. Cliccare sul bottone Finish per finire.

Selezionare il template appena aggiunto e ripetere l’operazione di editing. Click col tasto destro del mouse e selezionare la voce Edit Settings.

Adesso la pagina Properties viene visualizzata correttamente.

Risolta la fase di editing, riconvertire la virtual machine in template. Selezionare la vm, click col tasto destro del mouse e selezionare la voce Template –> Convert to Template.

Veloce procedura per risolvere un problema che può impattare sul fattore tempo spesso determinante nell’ambiente IT.

Hai già letto questi articoli?

Applicare le patch a VMware ESXi 4.1 tramite CLI

P@olo — Mon, 13 Dec 2010 06:00:00 +0000

Con l’uscita delle patch e degli aggiornamenti rilasciati da VMware, si pone il problema di come applicare queste patch al sistema ESXi.

La versione gratuita di ESXi è largamente utilizzata nei vari lab e spesso anche in produzione ma non è possibile utilizzare vCenter Server senza la sua licenza e nemmeno l’host update utility, precedentemente disponibile fino alla release 4.0, ora rimossa nella nuova versione 4.1.

L’unico modo è utilizzare la vSphere Command Line Interface comunemente chiamata CLI per applicare gli aggiornamenti agli host ESXi.

1. PREREQUISITI
Per poter eseguire la procedura di patching sono richiesti due componenti principali:

VMware vSphere CLI 4.1
Patch per ESXi

Installare VMware vSphere CLI sul proprio computer e scaricare dal sito VMware le patch per ESXi impostando i parametri di ricerca come in figura:

Selezionare la patch richiesta e cliccare sul bottone Download Now per scaricare il file .zip.

2. PROCEDURA
Prima di procedere con l’applicazione delle patch, tramite vSphere Client spegnere le virtual machine presenti nell’host e mettere il server ESXi in Maintenance Mode.

Una volta che il sistema è in Maintenance Mode, lanciare da Windows il Command Prompt per digitare i vari comandi di vSphere CLI.

Poichè il package scaricato filename.zip potrebbe contenere diversi file di patch da applicare (come in questo caso), visualizzare il contenuto del package tramite il comando:

vihostupdate.pl ––server IP_ESXi ––username root ––password password –b namefilepatch.zip –l

In questo package sono contenuti due file di patch o, per l‘esattezza, Bulletin ID.

ESXi410-201010401-SG
ESXi410-201010402-BG

Applicare le patch effettuando l’operazione per tutti i Bulletin ID contenuti nel package utilizzando l’istruzione:

vihostupdate.pl ––server IP_ESXi ––username root ––password password –i –b namefilepatch.zip –B BulletinID

Applicare la prima patch ESXi410-201010401-SG.

Applicare la seconda patch ESXi410-201010402-BG.

Da vSphere Client riavviare l’host ESXi.

Riavviato il sistema, uscire dalla Maintenance Mode. Ora è possibile riavviare nuovamente le virtual machine. Da notare il numero della versione riportata che adesso è variata dopo aver applicato le patch.

In questo modo siamo sicuri che il nostro sistema gode delle ultime patch e rimane allineato con gli aggiornamenti rilasciati periodicamente da VMware.

Hai già letto questi articoli?

Fix per com.vmware.converter error “Unable to retrieve health data from…” dopo la migrazione a vSphere 4.1

P@olo — Mon, 18 Oct 2010 06:00:00 +0000

Dopo aver completato l’installazione o la migrazione a VMware vSphere 4.1, aprendo il vCenter Service Status da vCenter Server, l’item com.vmware.converter viene viene marcato in red con uno status di Alert.

Questo problema non altera il corretto funzionamento del converter ed possibile effettuare le normali procedure di conversione senza errori.

L’errore riportato è il seguente:

Unable to retrieve health data from https://vCenter/converter/health.xml

Questo errore è dovuto ad un problema di handshake del certificato SSL.

La risoluzione del problema prevede la sostituzione del valore di thumbprint del Converter nel database ADAM LDAP con quella del vCenter Server.

1. PROCEDURA
Prima di iniziare l’operazione, l’effettuare un backup di vCenter Server mette al sicuro la funzionalità del sistema nel caso di imprevisti.

Per connettersi al server LDAP in vCenter Server, è necessario scaricare il file eseguibile ldp.exe, già presente nei Server 2008, e mandarlo in esecuzione.

Dal menu Start digitare ldp e premere Invio.

Viene aperta la finestra del programma Ldp. Cliccare su Connection –> Connect.

Digitare l’hostname del vCenter Server a cui connettersi e cliccare su OK.

Connessi al vCenter Server selezionato, cliccare su Connection –> Bind.

Nella maschera Bind, inserire le credenziali corrette per avere l’accesso al sistema.

Cliccare View –> Tree View.

Lasciare vuoto il campo BaseDN e cliccare su OK.

Effettuare un doppio click su DC=virtualcenter,DC=vmware,DC=int.

Doppio click su OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC=vmware,DC=int.

Doppio click su CN=.vpxd,CN=,OU=ComponentSpecs,OU=Health,
DC=virtualcenter,DC=vmware,DC=int.

Individuare nel lato destro l’attributo identificato dal nome vmw-vc-SSLThumbprint e prendere nota del suo valore (VALORE1).

Effettuare un doppio click su CN=com.vmware.converter,CN=,OU=ComponentSpecs,
OU=Health,DC=virtualcenter,DC=vmware,DC=int.

Annotare il valore dell’attributo vmw-vc-SSLThumbprint per ripristinarlo in caso di necessità.

Selezionare CN=com.vmware.converter,CN=,OU=ComponentSpecs,OU=Health,
DC=virtualcenter,DC=vmware,DC=int e cliccare col tasto destro del mouse. Selezionare Modify.

Inserire i parametri qui di seguito riportati:

Attribute: vmw-vc-SSLThumbprint
Values: il valore in CN=.vpxd… (passaggio marcato con ”VALORE1”)
Operation: Replace

Inseriti i parametri, cliccare su Enter (l’istruzione viene inserita nell’Entry List) e successivamente su Run. Click su Close per chiudere la finestra.

Il nuovo valore vmw-vc-SSLThumbprint è stato inserito nel database.

Riavviare i servizi VMware VirtualCenter Server e VMware VirtualCenter Management Webservices.

Selezionando il servizio VMware VirtualCenter Server, al momento del Restart anche i servizi associati vengono automaticamente riavviati.

Durante il riavvio dei servizi, il sistema mostra lo stato di avanzamento della procedura.

Riavviati i servizi, collegandosi nuovamente tramite vSphere Client al vCenter Service Status, com.vmware.converter non presenta più lo status di Alert ma risulta perfettamente operativo.

Poichè questa procedura agisce su un componente critico come vCenter Server, assicurarsi di avere il backup non solo del database VIM_VCDB ma anche del Server per ripristinare il tutto velocemente nel caso di problemi.

Hai già letto questi articoli?

Errore in vSphere 4.1 “Transaction log for database VIM_VCDB is full”

P@olo — Mon, 13 Sep 2010 06:25:28 +0000

Dopo aver avviato vSphere Client per la connessione a vCenter Server, compare un messaggio di Connection Error. Noto che questa non è la prima volta che capita dopo aver effettuato la migrazione a vSphere 4.1.

Il controllo quotidiano di vCenter Server fa parte delle attività di verifica per assicurare che la struttura virtuale sia perfettamente funzionante. Al presentarsi di un qualche problema può cambiare improvvisamente lo scenario del tipo di giornata che ci attende.

L’errore che si presenta è illustrato nella figura seguente.

A questo punto, dopo aver notato che il servizio VMware VirtualCenter Server non era avviato ho controllato i log di Windows per scoprire cosa fosse successo.

Il messaggio riportato indirizza immediatamente l’attenzione sul database MS-SQL. Ed è proprio qui che si deve operare per risolvere il problema.

1. PROCEDURA
Inanzitutto bisogna lanciare il Management Studio per accedere all’interfaccia di amministrazione di MS-SQL.

Per gestire la dimensione del Transaction Log in MS-SQL, bisogna agire sulla modalità di Recovery Model e sulla dimensione massima del Transaction Log nelle impostazioni del parametro di Autogrowth. Dal Management Studio fare click col tasto destro del mouse sul database VIM_VCDB e selezionare Properties.

Individuare l’opzione Recovery model e impostare il valore a Simple. Questo permette di poter effettuare lo shrink del Transaction Log.

Verificare la dimensione massima del file assegnata al parametro di Autogrowth. Per accedere a questo parametro, sempre dalla schermata Database Properties, selezionare la pagina Files e selezionare VIM_VCDB_log. Cliccare sul campo Autogrowth.

Se viene mantenuto come Recovery Model il valore Full può essere utile impostare il campo Restricted File Growth (MB) a 2048 per avere un certo margine.

A questo punto procedere con l’operazione di Shrink per liberare spazio nel Transaction Log file. Selezionare il DB, fare click col tasto destro e selezionare Tasks –> Shrink –> Files.

Come File Type selezionare Log e come Shrink action impostare l’opzione Release unused space. Click su OK. La dimensione del file di log viene così notevolmente rimpicciolita.

A questo punto avviando il servizio Windows VMware VirtualCenter Server è possibile collegarsi correttamente a vCenter tramite vSphere Client.

Ora che il file di log è di dimensioni accettabili, è possibile reimpostare il Model Recovery del database a Full per ripristinare la funzionalità del Transaction Log. VMware consiglia di lasciare il parametro Recovery Model settato a Simple per il database di vCenter server.

3. CAUSA
Analizzata la procedura per risolvere il problema, il motivo principale per cui si verifica la saturazione del file di log è dovuto alle impostazioni della raccolta delle statistiche da parte di vCenter.

Per accedere alla configurazione della raccolta statistiche, una volta connessi al vCenter Server cliccare su Administration –> vCenter Server Settings.

Cliccare su Statistics. Nella parte destra sono visualizzate le impostazioni. Il parametro che va verificato è Statistic Level che determina la quantità di informazioni raccolte.

Selezionando un valore nel campo Interval Duration e cliccando su Edit, si accede al livello di raccolta statistiche con valori che vanno da 1 a 4. Attenzione ad impostare il valore a 4 poichè imposta la raccolta delle statistiche a tutti i parametri disponibili a sistema con la conseguente ripercussione sul file di log.

4. CONCLUSIONE
Il Transaction Log del database VIM_VCDB è quindi influenzato da tre fattori principali:

MS-SQL Database – Recovery Model
Transaction Log – Restricted File Growth size
vCenter Server - Statistics Level

Agendo sulle impostazioni di queste tre opzioni, la dimensione del file di log è tenuta sotto controllo.

Hai già letto questi articoli?

Errore ADAM_VMwareVCMSDS in VMware vCenter 4.1 su Windows 2008 R2

P@olo — Mon, 30 Aug 2010 05:07:36 +0000

Dopo aver effettuato la migrazione a VMware vCenter 4.1, il log di Windows Server 2008 R2 riporta un warning piuttosto frequente inerente al servizio ADWS (Active Directory Web Services).

La descrizione dell’evento visualizza la seguente descrizione:

Active Directory Web Services encountered an error while reading the settings for the specified Active Directory Lightweight Directory Services instance. Active Directory Web Services will retry this operation periodically. In the mean time, this instance will be ignored.

Il log del servizio ADWS, visualizza una schermata di warning con una frequenza che non passa certo inosservata.

Facendo un po’ di ricerche su Google, ho trovato un articolo scritto da thesaffageek che spiega e illustra la soluzione al problema. Funziona perfettamente.

Ho testato con successo la procedura sul mio vCenter e ho approfittato per documentare tutti i passaggi.

1. PROCEDURA
Poichè il problema è relativo non tanto a vCenter ma a Windows

- Avviare Regedit

- Nel Registry Editor individuare la voce:

HKLM\SYSTEM\CurrentControlSet\Services\\Parameters

- Verificare che le voci di registro qui riportate siano configurate come REG_DWORD e abbiano i valori corretti:

Port LDAP –> REG_DWORD –> 389
Port SSL –> REG_DWORD –> 636

Nel mio sistema, la voce Port LDAP riportava una configurazione corretta mentre la voce Port SSL era del tipo REG_SZ con un valore non specificato.

- Se dovesse presentarsi uno scenario simile, semplicemente cancellare la voce Port SSL.

- Creare una nuova voce (tasto destro del mouse) di tipo DWORD (32-bit) Value ed effettuare un rename digitando come nome Port SSL.

- Impostare come Value data il numero 636 e cliccare su OK.

Adesso le due voci appaiono con i valori corretti come richiesto dal sistema.

- Per attivare la nuova configurazione, effettuare un restart del servizio ADWS.

Analizzando nuovamente il log del servizio, il messaggio che ora compare conferma che tutto funziona correttamente.

Il passaggio dalla versione vSphere 4.0 a 4.1 non sempre è immediata… rimane sempre qualche servizio da ottimizzare o da rimettere a posto (Update Manager ad esempio).

In fondo anche questo è un motivo che rende avvincente questo mondo…

Hai già letto questi articoli?

Modificare la directory di download di VMware Update Manager

P@olo — Wed, 07 Apr 2010 06:19:08 +0000

Quando vengono rilevati nuovi aggiornamenti delle categorie specificate nelle baseline in vCenter Server, il servizio vSphere Update Manager scarica gli update nella directory specificata durante la procedura di installazione.

Capita comunque che per esigenze di spazio disco o altro, è necessario modificare la directory di download. Reinstallare l’applicazione Update Manager permette di specificare la nuova directory di destinazione per gli aggiornamenti ma questo comporta ripetere l’intera operazione di installazione. Fortunatamente non è necessario rifare l’installazione poichè è possibile effettuare la modifica manualmente.

1. PROCEDURA
Per modificare la directory di download, procedere nel modo seguente:

- Il primo step è fermare da services.msc il servizio VMware Update Manager Service.

- Nel vCenter Server, identificare la directory C:\Program Files\VMware\Infrastructure\Update Manager e selezionare il file di configurazione vci-integrity.xml. Effettuare una copia del file nel caso si avesse l’esigenza di ripristinare la configurazione precedente.

- Editare il file vci-integrity.xml e modificare il path della directory di download indicata nei campi patchStore (D:\VMware_Updates\ nell’esempio) digitando il carattere \ alla fine della directory specificata.

D:\VMware_Updates\

- Copiare il contenuto dal vecchio patchstore alla nuova directory (D:\VMware_Updates).

- Riavviare il servizio VMware Update Manager Service.

A questo punto il nuovo repository per le patch e gli aggiornamenti di Update Manager è operativo nel nuovo path.

Hai già letto questi articoli?

Il servizio VMware vCenter Server non si riavvia dopo il reboot del server

P@olo — Wed, 31 Mar 2010 05:19:46 +0000

Se VMware vCenter Server e il database sono installati sulla stessa macchina, effettuando un’operazione di reboot i servizi VMware VirtualCenter Server e VMware VirtualCenter Management Webservices potrebbero non avviarsi.

Questo comporta che tramite vSphere Client non è possibile connettersi a vCenter e questo è un problema per la gestione dell’infrastruttura vSphere. Anche il servizio vCenter Service Status che monitora lo stato dell’hardware del sistema è influenzato da questa situazione e quindi non è operativo.

Il problema si manifesta quando si effettua il reboot del computer sul quale è installato vCenter Server: avviando vSphere Client non è possibile connettersi al server. Analizzando l’Event Viewer viene segnalato l’errore relativo al Virtual Center:

La descrizione dell’errore riportato risulta il seguente:

1. PROCEDURA IN WINDOWS 2003
Poichè agendo sulle Dependencies dei servizi coinvolti (come riportato in vari siti e forum) il problema non viene sempre risolto, indagini e ricerche più approfondite hanno portato all’identificazione di una procedura che ha risolto il problema riscontrato ripristinando la piena funzionalità del sistema.

Come prima cosa bisogna creare tramite un qualsiasi editor (Notepad ad esempio) uno script xx.bat che viene utilizzato per avviare i servizi.

- Nel file xx.bat, digitare le istruzioni indicate qui di seguito. In questo caso è utilizzato come database MS-SQL Express.

net start MSSQL$SQLEXP_VIM
ping 127.0.0.1 -n 30 -w 1000 > null
net start vpxd
net start vctomcat

- Salvare il file con nome, ad esempio start-service.bat.

Poichè lo script deve essere eseguito all’avvio del computer, bisogna configurare la policy di sistema per lanciare lo script durante lo startup.

- Cliccare su Start –> Run e digitare gpedit.msc, poi click OK.

- Posizionarsi in Computer Configuration –> Windows Settings –> Scripts e fare doppio click su Startup.

- Nella finestra Startup Properties che viene aperta, aggiungere lo script start-service.bat creato precedentemente tramite il bottone Add.

- Tramite Browse selezionare lo script creato e cliccare su OK.

- Da Start –> Run avviare services.msc ed impostare a Manual lo Startup Type dei due servizi VMware VirtualCenter Server e VMware VirtualCenter Management Webservices.

- Riavviare il vCenter Server.

- Una volta che il server ha terminato la procedura di startup, verificare che i due servizi siano stati effettivamente avviati.

2. PROCEDURA IN WINDOWS 2008
Se si utilizza Windows Server 2008 per far girare VMware vCenter, il problema del mancato avvio del servizio viene risolto anche in questo caso ritardandone l’avvio ma sfruttando la nuova opzione disponibile in questa versione di Windows.

- Accedere a Administrative Tools -> Services e selezionare il servizio VMware VirtualCenter Server.

- Fare click con il tasto destro del mouse e selezionare Properties.

- Impostare lo Startup type come Automatic (Delayed Start) e cliccare su OK.

Questo permette di ritardare l’avvio del Virtual Center dando modo al servizio SQL di completare lo startup rendendo disponibile il database prima che vCenter tenti di accedere.

Con queste impostazioni il servizio VMware VCenter viene avviato correttamente ad ogni reboot del server.