New Advanced Deploy vSphere 6.5 Exam - 3V0-21.18

La settimana scorsa mi sono trovato a sostenere il nuovo esame "Advanced Deploy vSphere 6.5 Exam 2018" e volevo condividere alcune problematiche riscontrate, dovute spero, alla giovane età dell'esame.

VCAP-DCV 2018 Deploy Exam Details:
Exam Duration: 205 minutes
Number of Questions: 17 Questions
Passing Score: 300
Cost: $450
Format: Lab-based, Proctored

VCAP-DCV 2018 Deploy Exam Guide:
Exam Preparation Guide:
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/certification/vmware-vcap-dcv-2018-exam-prep-guide.pdf
Reference: https://www.vmware.com/education-services/certification/vcap-dcv-deploy-2018-exam.html

Il primo problema l'ho riscontrato nello schedulare l'esame. L'esame risulta essere disponibile sul sito della Pearson Vue, una volta scelto il centro dove sostenerlo non mi viene presentato nessun "calendar" per poterlo schedulare (giorno ed ora). In prima battuta ho pensato che fosse un problema del centro, magari non c'erano disponibilità in quella data. Ho quindi, provato a selezionare un altro centro ma con lo stesso risultato. Ho provato a selezionare vari centri a Milano, Roma, Bologna ..... sembra che questo esame non si possa schedulare.
L'unico modo che ho trovato per poterlo schedulare è stato, chiamando il supporto Pearson Vue.

Premesso: sapevo che l'esito di quest'esame non fosse immediato. Mi aspettavo dopo qualche ora di ricevere una email con l'esito dell'esame, ma nulla di fatto. Il giorno successivo non avendo ricevuto nessun tipo di notifica decido di scrivere al servizio Education di VMware chiedendo informazioni. Ehhh, dopo essere passato per varie persone del supporto, esattamente dopo una settimana dall'esame vengo a scoprire che il risultato di questo nuovo esame sarà disponibile tra le 4 e le 6 settimane....

non mi resta che incrociare le dita ed attendere.

Di seguito alcuni link utili per la preparazione all'esame:
VCAP6-DCV Deploy Exam Simulator – FREE (virtualg.uk)
VCAP6-DCV Deploy Practice (sostechblog.com)
VCAP6-DCV Deployment Exam Preparation (shirazerosagon.blogspot.com)
VCAP6-DCV Deployment Study Guide (vjenner.com)
VMware Hands-on Lab (VMware)

Ultimo consiglio utilizzare quotidianamente ESXi :-)

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.