Corrispondenze tra versioni VxRail e VMware Build Numbers

Mi trovo alle prese con l'aggiornamento di una infrastruttura VxRAIL, dove il vCenter Server e la PSC Server sono esterni all'infrastruttura Dell EMC e quindi con la necessità di avere in fase di upgrade tutte le varie componenti come VxRAIL Manager, vCenter server/vSAN, nodi ESXi (build numbers), ESRS, Log Insight, ecc. in matrice.

Tutti gli aggiornamenti relativi all'infrastruttura VxRail vengono effettuati dal VxRail Manager e non direttamente dal VC o sui nodi ESXi.

Ho quindi la necessità di avere una tabella comparativa che mi permetta di correlare le versioni di VMware con quanto presente all'interno dei "composite package" rilasciati da Dell EMC.

Ecco trovata una KB52075 ufficiale di VMware con una tabella delle versioni corrispondenti di VxRail e VMware. Tuttavia la KB trovata sembra non essere stata aggiornata di recente. Le informazioni che sto ricercando non sono presenti.

Cercando le stesse informazioni all'interno del sito di supporto Dell EMC, trovo quanto mi serve nel documento "VxRail support Matrix".

VMware vRealize Operations Manager - Data Retriever is not inizialized yet. Please wait...

Problema

Un cliente lamenta l'impossibilità di accedere tramite web alla GUI di VMware vRealize Operations Manager. 
Non si ha la possibilità di inserire le proprie credenziali in quanto la pagina è in stallo con il messaggio "Data Retriever is not inizialized yet. Please wait..." 

Soluzione
Prima di effettuare quando indicato di seguito spegnere la VM ed effettuare una Snapshot in modo da avere un punto di ripristino più o meno corretto.

1. Loggarsi all'interno della Virtual appliance tramite SSH o direttamente dalla console VMware (come è stato per il mio caso)... ed iniziare ad analizzare l'occupazione disco con il comando "df -h".
   
   
   
   
   Come possibile vedere dall'immagine sopra, non c'è più spazio dedicato ai log.
   
2. Accediamo alla cartella "/storage/log" ed analizziamo lo spazio nelle varie cartelle ...
   
   
   
   
   
3. Analizziamo inizialmente la cartella "/storage/log/var" alla ricerca di file da rimuovere. Come possiamo vedere dall'immagine sotto:
   - "messages" occupa 2.1GB
   - "auth.log" occupa 2.6GB
   
   
   
4. Stoppiamo il servizio syslog ("/etc/init.d/syslog stop") e procediamo ad azzerare i due file nel con il seguente comando:
   - echo > messages
   - echo > auth.log
   
   
   
5. Spostiamoci ora, ad analizzare la cartella "/storage/log/vcops/log".
   Da una prima analisi abbiamo notato che la cartella è popolata da moltissimi file (nello specifico 8858) di cui molti sono di dimensioni 0.
   
   
   
   
   
   
   
   
6. Dopo una veloce ricerca su google.... abbiamo trovato la KB corretta che può aiutarci a ripulire correttamente la cartella "/storage/log/vcops/log" al seguente link "Safely cleaning up log files in vRealize Operations 6.x (2145578)"
7. Seguita alla lettera la KB VMware. Eseguiamo un reboot dell'intera appliance ..... et voilà
   
   
   
   
   siamo nuovamente in grado di poter inserire le credenziali per il login.

vRealize Operations Manager Appliance - lost local root password

Problema

Ho la necessità di accedere in console a "VMware vRealize Operation Manager" appliance per risolvere/verificare una problematica segnalata da un cliente.
Il problema è che il cliente non ricorda più la password di root dell'appliance.

Soluzione
Niente panico!! :-) procediamo con il reset come indicato nella KB2001476.

1.  Per Prima cosa procediamo con lo spegnere la VM
   
   
   
   
2. Con la console aperta, ri-avviamo la virtual machine.
   
3. Quando appare il GRUB loader menu, selezionare l'entry corrispondente al normale avvio di sistema nel mio caso "SUSE Linux Enterprise Server 11 SP3 for VMware - 3.0.101-0.47.52". Aggiungere alla riga di boot la stringa "init=/bin/sh" come da immagine sotto ed avviare normalmente
   
   
   
   
4. Quando ci viene presentato il prompt "sh-3.2#" digitare "passwd root" digitare e confermare la nuova password inserita. Riavviare l'appliance con reboot.
   
   
   
   
5. Riavviato il sistema è possibile loggarsi all'interno con le credenziali precedentemente impostate.
   

PowerCLI 10.2.0 Updates - Manual removal of unnecessary modules

Disclaimer: Some of the procedures described below is not officially supported by VMware. Use it at you own risk.

Il 20 Agosto 2018, è stata rilasciata la nuova PowerCLI 10.2.0 con i seguenti aggiornamenti: 

• Support for NSX-T 2.2
• Deprecation of the PCloud module, so look for this module to be removed in the future
• Update to Get-VIEvent to resolve the issue when receiving: Error in deserializing body of reply message for operation 'RetrieveProperties'

maggiori informazioni possono essere trovare sul blog ufficiale VMware a questo link.

L'update della PowerCLI, di per se è semplice. E' sufficiente lanciare il comando...

PS /Users/lorenzo>  Update-Module -Name VMware.PowerCLI

... di fatto per i puristi è da far notare che i "vecchi" moduli non vengono rimossi e/o rimpiazzati dalle nuove versioni; ma restano sul sistema.

Come indicato, anche nella "VMware PowerCLI 10.2.0 User's Guide" nel paragrafo "Update a PowerCLI Module", è consigliato rimuovere i moduli  per poi re- installarli ..... 

Non conoscendo quali sono i moduli che sono stati aggiornati con il rilascio della versione 10.2.0, sarebbe opportuno rimuovere completamente la PowerCLI per poi re-installarla. 

Di seguito utilizzeremo un metodo diverso.... procederemo in primis con l'update della PowerCLI e poi con la rimozione dei vecchi moduli.

Per prima cosa prendiamo visione dei moduli attualmente installati ...

PS /Users/lorenzo> Get-Module -Name  VMware.* -ListAvailable

Procediamo con l'update ...

PS /Users/lorenzo> Update-Module-Name VMware.PowerCLI

e confermiamo premendo "Y". Terminato l'update verifichiamo quali moduli sono presenti sul sistema ...

PS /Users/lorenzo> Get-Module -Name VMware.* -ListAvailable

Come possiamo notare, ci sono dei moduli che sono presenti in più versioni.

Per una corretta rimozione dei dati, verifichiamo come sono le dipendenze della nuova PowerCLI

PS /Users/lorenzo> (Get-Module VMware.PowerCLI -ListAvailable).RequiredModules

Procediamo con la rimozione corretta dei moduli in questo  modo

1. Prendiamo nota della versione "esatta" del modulo da rimuovere ...
   

   PS /Users/lorenzo> Get-Module -Name VMware.PowerCLI -ListAvailable | select version

   

   
   Nel nostro caso "10.1.1.8827524" .....
2. .... procediamo con la rimozione forzata del modulo (indipendentemente dalla dipendenze che possa avere).
   

   PS /Users/lorenzo> Uninstall-Module -Name VMware.PowerCLI -RequiredVersion 10.1.1.8827524 -force

   

   
   
3. Verifichiamo che sia presente nel sistema solo la versione corretta ... 

   PS /Users/lorenzo> Get-Module -Name VMware.PowerCLI -ListAvailable

   

   
   
4. Ripetiamo i precedenti punti da 1 a 3 anche per i moduli "VMware.Vim" e "VMware.VimAutomation.Nsxt"
5. Verifichiamo la lista completa dei moduli corrisponda a quella dei moduli richiesti dalla PowerCLI 10.2.0
   
   

   PS /Users/lorenzo> Get-Module VMware* -ListAvailable

   

   
   

-----------------------------------------------------------

Update del post:

come confermato da Kyle Ruddy non c'è la necessità di tenere tutte le vecchie versioni dei moduli installate nel sistema ... 

PowerCli to configure and modify Syslog on Hosts ESXi

Problema

Più che un problema, oggi ho una necessità di modificare le impostazioni SYSLOG di tutti gli Host ESXi che appartengono ad un determinato vCenter per re-indirizzare i log su di un nuovo syslog server. 

Il parametro da modificare è Syslog.global.logHost ... 

e per modificarlo (se effettuato via Web Client) occorre cliccare sul nodo ESXi, Configure -> Advanced System Settings -> ricercare la variabile syslog; selezionare la riga e quindi cliccare su EDIT

... ed una volta modificato il valore con le nuove impostazioni premere OK. Semplice attività da svolgere se di deve fare su un numero limitato di host ESXi, un pò più lungo e macchinoso se la modifica da fare è su un numero N di nodi dove N è >= 50 host ESXi. Da questa semplice problematica, nasce l'esigenza di poter automatizzare questa procedura tramite la scrittura di qualche riga in PowerShell.  

Soluzione

Nota: Per effettuare i test descritti di seguito ho utilizzato gli HOL (Hands On Labs di VMware); prima di provarli in produzione. Nello specifico ho utilizzato il lab HOL-1911-01-SDC.

Per risolvere quanto appena descritto ho realizzato due scripts, il primo per verificare le impostazioni (con la possibilità di re-indirizzarle su un file esterno l'output in modo da potersi salvare le attuali configurazioni), il secondo per modificare i valori della variabile indicata.

Come prima cosa occorre connettersi al vCenter, aprendo una powershell utilizzando il comando ... Connect-VIServer <vCenter Name>. Nel mio caso Connect-VIServer vcsa-01a.corp.local 

Visualizzazione delle impostazioni.

foreach ($ESXi in Get-VMHost) {

Get-AdvancedSetting -Name "Syslog.global.logHost" -Entity $ESXi.Name | Select Value

}

Sostituzione con il nuovo IP "udp://10.1.1.1:514"...

foreach ($ESXi in Get-VMHost) {

Get-AdvancedSetting -Name "Syslog.global.logHost" -Entity $ESXi.Name | Set-AdvancedSetting -Value "udp://10.1.1.1:514" -Confirm:$false

}

verifichiamo l'avvenuta modifica sia via script  ....

che via web client ...

Problema risolto.

How to cancel an hang task of a VM?

Problema
Una VM risulta essere bloccata, non risponde più al ping, non si riescono ad effettuare le normali attività di gestione della VM come, migrazione, riavvio, spegnimento della VM ecc.
Tutto, per questa VM sembra essere in uno stato di blocco impossibile da annullare, la stessa VM è in fase di migrazione da un host esxi ad un altro da oltre 24 ore.

Come possibile vedere dall'immagine sotto, quando si provava a spegnere via web client la VM si otteneva il seguente messaggio di errore: "The attempted operation cannot be performed in the current state ("Powered on"). An error was received from ESX host while powering off VM <VM NAME>."

Idem provando via command line direttamente sull'host ESXi con i vari comandi vim-cmd, si ottiene lo stesso messaggio di errore. 
Non resta che "killare" il processo che gestisce la VM procedendo nel seguente modo:

• 1. Lanciare il comando ps.
• 2. Identificare i processi in esecuzione relativi alla VM problematica usando il comando grep in questo modo "ps | grep VM-Name". Nel mio caso la VM si chiama COGNOS_TEST, quindi "ps | grep COGNOS_TEST"
• 3. Uccidere (kill) il processo genitore (parent) con il comando "kill Parent_ID". In questo caso "kill 4730011"

Verificato che i processi relativi alla VM non sono più in esecuzione.... la VM risulta ancora accesa e quando si prova a spegnerla, si ottiene il solito messaggio di errore.

Soluzione

La soluzione trovata indicata anche dalla seguente KB1014165 ... è stata quella di verificare i processi relativi alla VM bloccata con i comandi esxicli nel modo seguente:

• 1. Lanciare il comando "esxcli vm process list" per identificare il "World ID" della VM. Nel mio caso "4730012"

• 2. Spegnere brutalmente la VM con il comando "esxcli vm process kill -t [soft, hard, force] -w World_ID". Nel mio caso "esxcli vm process kill -t force -w 4730012 " 

• 3. In questo caso la VM risulta essersi spenta.

VMware Identity Manager 2.9 – Could not Pull the Required Object From Identity Manager

Disclaimer: Some of the procedures described below is not officially supported by VMware. Use it at you own risk.

Problema
Sono stato contattato da un cliente perché l'Identity Manager che avevo messo in piedi un pò di tempo fa, sembra non autenticare più correttamente gli utenti. Sembra che l'IDM non contatti più i Domain Controllers.
Effettuato il login come utente amministratore all'interno dell'Appliance IDM (nel mio caso l'IDM è una versione 2.9.2.0 Build 6095217) vado a verificare sotto la tab Identiry & Access Management i Directories e noto che a fianco del bottone Sync Now nella riga corrispondente del Directory Name interessato c'è una X rossa che indica che l'IDM non riesce correttamente a sincronizzarsi/contattare l'AD (Active Directory).
Clicco quindi sul Sync Now  e vado a verificare in Sync Log cosa sta succedendo; il seguente messaggio di errore:

Could not pull the required object from Identity Manager

Ci si connette in SSH sull'Identity Manager cercando di reperire maggiori info dai file di logs. 
I file di logs per quello che riguarda l'vIDM sono nella directory "/opt/vmware/horizon/workspace/logs/"  nello specifico ho trovo alcune informazioni interessanti nel file di log connector.log (vedi sotto)

2018-06-20 14:11:28,514 INFO  (Timer-24) [3002@WSIDM;;] com.vmware.horizon.connector.admin.StateService - Saving config for 3002@WSIDM to file /usr/local/horizon/conf/states/WSIDM/3002/config-state.json
2018-06-20 14:11:28,521 INFO  (Timer-24) [3002@WSIDM;;] com.vmware.horizon.connector.admin.StateService - Saving state config to disk DONE.
2018-06-20 14:12:26,057 INFO  (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.utils.RestClient - END   sendRequestBase (https://wsidm.<NOME CLIENTE>.it/SAAS/t/wsidm/jersey/manager/api/connectormanagement/directoryconfigs/19321c7b-0172-4eaa-89b4-c54a316a4514/syncprofile, ..., application/vnd.vmware.horizon.manager.connector.management.directory.sync.profile+json, GET, null, ...)
2018-06-20 14:12:26,057 WARN  (Timer-18) [3002@WSIDM;; com.vmware.horizon.engine.ObjectPullEngine - Code from Service :-404
2018-06-20 14:12:26,057 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.engine.ObjectPullEngine - Error message from Service :-Request timed out..[response-Request timed out.
2018-06-20 14:12:26,057 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.engine.ObjectPullEngine - Could not retrieve required object from Horizon com.vmware.horizon.connector.exception.PullEngineException: Could not retrieve required object from Horizon
        at com.vmware.horizon.engine.ObjectPullEngine.getObjectFromHorizon(ObjectPullEngine.java:98)
        at com.vmware.horizon.connector.connectormanagement.DirectorySyncConfigPullEngine.getDirectorySyncConfigFromService(DirectorySyncConfigPullEngine.java:44)
        at com.vmware.horizon.connector.admin.DirectorySyncConfigUpdateService.updateDirectorySyncConfigFromService(DirectorySyncConfigUpdateService.java:43)
        at com.vmware.horizon.connector.admin.SyncScheduleService.syncIfAppropriate(SyncScheduleService.java:153)
        at com.vmware.horizon.connector.admin.ScheduleService$1.run(ScheduleService.java:83)
        at java.util.TimerThread.mainLoop(Timer.java:555)
        atjava.util.TimerThread.run(Timer.java:505)
2018-06-20 14:12:26,060 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.admin.ScheduleService - Sync of Directory aborted.com.vmware.horizon.connector.exception.PullEngineException: Could not retrieve required object from Horizon<
        at com.vmware.horizon.engine.ObjectPullEngine.getObjectFromHorizon(ObjectPullEngine.java:98)
        at com.vmware.horizon.connector.connectormanagement.DirectorySyncConfigPullEngine.getDirectorySyncConfigFromService(DirectorySyncConfigPullEngine.java:44)
        at com.vmware.horizon.connector.admin.DirectorySyncConfigUpdateService.updateDirectorySyncConfigFromService(DirectorySyncConfigUpdateService.java:43)
        at com.vmware.horizon.connector.admin.SyncScheduleService.syncIfAppropriate(SyncScheduleService.java:153)
        at com.vmware.horizon.connector.admin.ScheduleService$1.run(ScheduleService.java:83)
        at java.util.TimerThread.mainLoop(Timer.java:555)
        at java.util.TimerThread.run(Timer.java:505)
2018-06-20 14:12:26,060 INFO  (SimpleAsyncTaskExecutor-171294) [3002@WSIDM;;] com.vmware.horizon.client.rest.Utils -BEGIN sendRequestBase (https://wsidm.< NOME CLIENTE>.it/SAAS/t/wsidm/API/1.0/REST/auth/cert, ..., application/x-www-form-urlencoded, GET, null, ...)
2018-06-20 14:12:26,060 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.mvc.UIAlerts - Could not pull the required object from Identity Manager. Request timed out..[response-Request timed out.]
2018-06-20 14:12:26,060 INFO  (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.admin.SyncScheduleService - Directory sync method: end.
2018-06-20 14:12:26,070 INFO  (SimpleAsyncTaskExecutor-171294) [3002@WSIDM;;] com.vmware.horizon.client.rest.Utils -END   sendRequestBase (https://wsidm.<NOME CLIENTE>.it/SAAS/t/wsidm/API/1.0/REST/auth/cert, ..., application/x-www-form-ur lencoded, GET, null, ...)

Noto una entry con "Could not retrieve required object from Horizon", il che mi fa pensare a qualche cambiamento di cui non sono a conoscenza :-) ..... googlando un pochino la stringa presente nell'interfaccia web "Could not Pull the Required Object From Identity Manager" vedo che non sono l'unico con il problema e trovo un interessante post di Matt Allfrod a questo link .

Chiedo quindi al cliente se ci sono cambiamenti con i Domain Controllers e scopro che uno di questi è stato spento (perché dismesso).

L'Identity Manager una volta configurato non effettua automaticamente delle query per verificare quali sono i Domain Controllers disponibili, ma fa riferimento ad un file "domain_krb.properties" creato in fase di configurazione.

Documentazione ufficiale VMware nell'area Integrazione con Active directory

Individuato il nome del DC dismesso procediamo alla modifica manuale del fie domain_krb.properties nel modo seguente:

1. effettuare il login all'interno dell'vIDM (Utilizzare sshuser e poi diventare root)

2. effettuare una copia del file originale 

cp /usr/local/horizon/conf/domain_krb.properties  /usr/local/horizon/conf/domain_krb.properties .ORIG

3.editare il file vi /usr/local/horizon/conf/domain_krb.properties

4. effettuare le modifiche in base ai cambiamenti dei Domain Controller e salvare le modifiche. Nel nostro caso eliminare la entry del DC che non esiste più.

5. cambiare l'ownership del file eseguendo 

chown horizon:www /usr/local/horizon/conf/domain_krb.properties

6. riavviare il servizio eseguendo service horizon-workspace restart

7. lanciare un Sync Now per verificarne il corretto funzionamento.

Con mia sorpresa mi accorgo che la procedura appena indicata non ha sortito effetto, il problema è ancora lì ed l'vIDM continua a non sincronizzarsi correttamente con l'infrastruttura Active Directory.

Soluzione

Analizzando in modo più approfondito i file di logs del connector ed ispirato dalla KB2145438 ho notato che tutte le richieste effettuate sembrano essere iniziate da un initiator (nel mio caso 3002@<nome server>) che ha un file di configurazione posizionato in /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json (vedi sopra riga 1 nel file di log).

Verificando il contenuto del file config-state.json, riscontro che ci sono delle entry con il nome del Domain Controller dismesso. 

Decido quindi di procedere come d seguito...

8. effettuare una copia del file  sorgente (prima di effettuare qualsiasi modifica) nel modo seguente... cp /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json.ORIG

wsidm:~ # cp /usr/local/horizon/conf/states/WSIDM/3002/config-state.json /usr/local/horizon/conf/states/WSIDM/3002/config-state.json.ORIG

9. sostituisco il nome del DC dismesso con uno esistente sed -i 's/<DC Vecchio>/<Nuovo DC>/g' /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json

wsidm:~ # sed -i 's/sgrsodc2017/sgrbodc2/g' /usr/local/horizon/conf/states/WSIDM/3002/config-state.json 

10. riavviare il servizio eseguendo service horizon-workspace restart 

11. lanciare un Sync Now per verificarne il corretto funzionamento

12. Verificare l'accesso con una utenza di servizio. Avendo utilizzato un DC prossimo all'vIDM, a sensazione (non avendolo monitorato) la procedura di autenticazione è sembrata più veloce.

Conclusione

Consiglio di verificare tutti gli step indicati, sia per modificare il file  domain_krb.properties (eliminando i DC non più presenti) e sostituendo le entry del DC dismesso all'interno del file config-state.json con con un DC in cui è abilitata la ricerca della Posizione servizio DNS (record SRV) come indicato qui.