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.