VxRail vSAN - Time is synchronized across hosts and VC

Problema
Inserendo dei nuovi nodi VxRail ad un cluster esistente .... lo status del cluster in vSAN -> Health -> Cluster -> "Time is synchronized across hosts and VC" ... cliccando il pulsante "Ask VMware" non ottengo informazioni utili alla risoluzione del problema.

Verificato che l'NTP server sia lo stesso e correttamente impostato su tutti gli host ESXi, vCenter compreso; verifico ulteriormente se l'orario riportato sugli host differisce di qualche minuto. Ahii me tutto gli hosts ed il vCenter sono perfettamente allineati.

Soluzione
Il problema nel mio caso è stato risolto riavviando PSC e vCenter.

NSX Manager - Access to PostgreSQL

Disclaimer: Don't try this on NSX production environment.

In un precedente post "NSX Manager - Tech Support Access" ho descritto come accedere in modalità "engineering" alla console di NSX Manager.

In questo post mostro come poter accedere al PostgresSQL della console NSX Manager per reperire informazioni contenute all'interno delle varie tabelle.

Ripeto, quanto indicato nel disclaimer: quanto descritto non va testato in un ambiente in produzione in quanto qualsiasi modifica al sistema sottostante se non con l'aiuto del supporto tecnico di VMware potrebbe avere come risultato che il sistema non venga più supportato dal GSS. Consiglio di effettuare un backup dell'appliance, unica modalità valida per salvarsi le impostazioni dell'intera infrastruttura NSX.

Quanto descritto di seguito l'ho testato on line utilizzando i laboratori "nested" pre-configurati da VMware per valutare le diverse funzionalità dei prodotti; nel mio caso ho utilizzato uno di quelli relativi a NSX. Per accedere agli Hands on Lab (HOL) è necessario disporre di un account. Se non si dispone dell'account, per poter accedere ai LABs è possibile compilare la form di registrazione in modo gratuito.

Procediamo nel seguente modo:

1. Accedere tramite "Putty" e/o SSH alla console NSX Manager con l'utenza "admin" ed immettere la rispettiva password
   
   
   
   
   
2. Ottenuto l'accesso in modalità "Engineering" ....
   
   
   
   
   
3. Per accedere al DataBase PosrgreSQL dobbiamo utilizzare l'utenza "secureall". Procediamo digitando dal prompt dei comandi "psql -U secureall"
   
   
   
   
   
4. Ottenuto l'accesso al database digitare "\d" per ottenere la lista delle tabelle presenti ...
   
   
   
   
   
   Segue la lista delle tabelle presenti nel DB. Dal prompt è possibile interagire con il DB tramite i comandi standard SQL, quindi interrogare le tabelle tramite SQL e/o effettuare inserimenti, modifiche, cancellazioni ecc. ecc.
   
   
   

Per il momento questo è tutto, ma immaginate quante cose sono possibili fare avendo accesso al DB principale .....

NSX Manager - Tech Support Access

Disclaimer: Don't try this on NSX production environment.

VMware, un pò di tempo fa, ha reso pubbliche tramite la KB 2149630 le informazioni sul come poter accedere in modalità "Tech Support Mode" e/o "root shell" alla console NSX Manager.

Ripeto: quanto descritto non va testato in un ambiente in produzione in quanto qualsiasi modifica al sistema sottostante se non con l'aiuto del supporto tecnico di VMware potrebbe avere come risultato che il sistema non venga più supportato dal GSS.

Quanto descritto di seguito l'ho testato on line utilizzando i laboratori "nested" pre-configurati da VMware per valutare le diverse funzionalità dei prodotti; nel mio caso ho utilizzato uno di quelli relativi a NSX. Per accedere agli Hands on Lab (HOL) è necessario disporre di un account. Se non si dispone dell'account, per poter accedere ai LABs è possibile compilare la form di registrazione in modo gratuito.

Procediamo nel seguente modo:

1. Accedere tramite "Putty" e/o SSH alla console NSX Manager con l'utenza "admin" ed immettere la rispettiva password
   
   
   
   
   
2. Dalla NSX Manager CLI, digitare "ena"<enter> fornire la password inserita nella fase di installazione dell'NSX Manager, in modo da avere una sorta di accesso root.
   
   
3. Dal prompt della modalità enable, entrare in modalità "engineering" digitando st eng<enter>.
   
   
4. Al messaggio di Warning:
   
   Engineering Mode: The authorized NSX Manager system administrator is requesting a shell which is able to perform lower level unix commands/diagnostics and make changes to the appliance. VMware asks that you do so only in conjunction with a support call to prevent breaking your virtual infrastructure. Please enter the shell diagnostics string before proceeding.Type Exit to return to the NSX shell. Type y to continue: y.
   
   Premere "y"
   
   
5. Inserire la seguente password "IAmOnThePhoneWithTechSupport"
   
   

Questo per il momento è tutto, maggiori dettagli si possono trovare sulla pagina VMware KB2149630

Update Manager (Remediate) - Cannot execute upgrade script on host

Problema
Il processo di aggiornamento della "Remediate" si blocca all'88% con il seguente messaggio di errore:

"Cannot execute upgrade script on host"

Soluzione
Verifichiamo i log dell'update manager relativi all'host ESXi che si sta aggiornando su vCenter in "/var/log/vmware/vmware-updatemgr/vum-server/hostUpgrade/" nel seguente modo ...

(1) root@mgmt-vc01 [ /var/log/vmware/vmware-updatemgr/vum-server/hostUpgrade ]# cat vua-esx24.<FQDN>-index

nel mio caso come output ho il valore 7(2), che sta ad indicare che il log attivo dove sono presenti le informazioni è il 7(2). Quindi ...

(3) root@mgmt-vc01 [ /var/log/vmware/vmware-updatemgr/vum-server/hostUpgrade ]# cat vua-esx24.<FQDN>-7.log

-->         <value>True</value>
-->       </expected>
-->       <found>
-->         <value>True</value>
-->       </found>
-->       <result>SUCCESS</result>
-->     </test>
-->
-->  </tests>
--> </precheck>
-->
--> </result><err> Failed to load locker vib database: ('/locker/packages/var/db/locker', 'Error reading Vib xml from database /locker/packages/var/db/locker: VibCollection directory /locker/packages/var/db/locker/vibs does not exist.')
--> </err></output>
2019-01-23T11:01:15.896Z info vua[18046080] [Originator@6876 sub=VUA] Function call finished
2019-01-23T11:01:15.896Z info vua[18046080] [Originator@6876 sub=VUA] Sending response: <output><exitCode>0</exitCode><r ...
2019-01-23T11:01:15.899Z info vua[18046088] [Originator@6876 sub=VUA] Handling post request
2019-01-23T11:01:15.900Z info vua[18046088] [Originator@6876 sub=VUA] Received call for function getlog
2019-01-23T11:01:15.900Z info vua[18046088] [Originator@6876 sub=VUA] Invoking: "/bin/cp -f /var/log/vua.log /var/log/vua.log.cpy"
2019-01-23T11:01:15.900Z info vua[18046088] [Originator@6876 sub=SysCommandPosix] ForkExec(/bin/cp) 18046132
root@mgmt-vc01 [ /var/log/vmware/vmware-updatemgr/vum-server/hostUpgrade ]#

Ricercando il messaggio di errore su Google :
Failed to load locker vib database: ('/locker/packages/var/db/locker', 'Error reading Vib xml from database /locker/packages/var/db/locker: VibCollection directory /locker/packages/var/db/locker/vibs does not exist.')
il primo link disponibile è la KB2030665 "The host returns esxupdate error code:15" error when remediating an ESXi 5.x and 6.x host (2030665)". Anche se, dal titolo non sembra esattamente soddisfare le mie esigenze, leggendo all'interno trovo degli spunti interessanti da verificare/provare.

Decido quindi di ispezionare la folder "/locker/packages/var/db/locker"....

mettere in "maintenance" il nodo e rinominare le attuali directory <NAME>.new in <NAME>

Premere nuovamente il bottone "Remediate"

Questa volta il processo di remediation è terminato correttamente!!

Site Recovery Manager (SRM) 8.1 Replacing certificate fails with the error: Failed to validate certificate.

Problema
In fase di aggiornamento/sostituzione dei certificati su di una infrastruttura Site Recovery Manager (SRM) 8.1 come descritto in questo documento VMware "Replace the VMware Site Recovery Manager Certificates".

Abbiamo ottenuto il messaggio di errore: "Failed to validate certificate. Details: Internal Error."

Soluzione
Da una prima veloce ricerca su google sono approdato alla KB2091089 ("Installing VMware vCenter Site Recovery Manager (SRM) 5.8 with a Pcks12 certificate package fails with the error: Failed to validate certificate"). Sfortunatamente, pur eseguendo quanto indicato non ha risolto il problema. Ottengo sempre il solito messaggio di errore.

Decido quindi di analizzare in dettaglio i log di sistema in "C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs" ... nel mio caso l'ultimo file scritto dal sistema è "srm-config-36.log"

Verificando all'interno riscontro "Command failed: ... Certificate is CA or does not have an SSL server purpose."

Il certificato non è stato firmato in modo corretto dalla CA.
Verificando con l'amministratore di sistema della Certification Authority interna i requisiti necessari .."Requirements When Using Custom SSL/TLS Certificates with Site Recovery Manager".

Riscontriamo che il template utilizzato per firmare non rispettava correttamente i parametri richiesti indicati nei requirements ....
"The certificate must be a server certificate, for which the x509v3 Extended Key Usage must indicate TLS Web Server Authentication."

Ri-sottoposto a firma, questa volta con i parametri indicati come da requisiti :) :) (grazie Andrea e Renzo per l'aiuto.) .... siamo stati in grado di procedere con la sostituzione del certificato.... e di portare a termine il nostro compito.

vEXPERT 2019

vExpert 2019 Award Announcement

Sono orgoglioso di aver ricevuto per il secondo anno consecutivo da parte della vCommunity il riconoscimento di vExpert 2019.

La lista completa è disponibile a questo link.

Tengo a ribadire che il titolo di "vExpert" non è una certificazione tecnica ma più un premio dato alle attività individuali di informazione, evangelizzazione e di condivisione delle proprie passioni in ambito VMware.

Un grande ringraziamento da parte mia a VMware ed a tutti coloro che hanno permesso questo.