[Nested ESXi] - How to properly configure it

Issue

Working within a LAB and/or in a nested environment often requires the deployment of new ESXi hosts. The fastest way to have new ESXi hosts deployed quickly is to clone them from a master VM.
Below few steps to follow to properly create a working VM clone in a nested environment.

Solution

• First of all, we do a normal installation in a neste environment of our ESXi master VM, giving to it minimal resources, as:
  - 2 vCPU
  - 8 GB of RAM
  - 20GB of Disk (Thin Provision)
  - 4 vNIC
  
  
  
  
  
• When started, we get into ssh and we change the VMkernel MAC address by running the following command:
  
  esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1
  
  
• To have the unique UUID on each host, we need to delete the "/system/uuid" record stored in /etc/vmware/esx.conf. To do this we can edit the file and delete the corresponding line, or launch the command below, which replaces the corresponding line with an empty line.
  
  sed -i 's/^\(\/system\/uuid\).*//' /etc/vmware/esx.conf
  
  
  
  
  
  
• It is possible to shutdown the ESXi master VM and convert it to a template, or leave it as is to be cloned later when needed.
  
  
  
• When needed, we can clone the master VM to deploy our ESXi nodes. On starting up of the VM, a new UUID will be generated.
  Once the ESXi VM clones is pawered on, we can change network settings on them (IP addresses, hostnames, etc.).
  
  
• Let's generate a new certificate, typing the following command:
  
  /sbin/generate-certificates
  
  
• Let's restart the following services, in order to make the host ready for our LAB.
  
  /etc/init.d/hostd restart && /etc/init.d/vpxa restart
  
  
  

That's it.

VMFS-6 heap memory exhaustion on vSphere 7.0 ESXi hosts (80188)

Issue

I recently experienced the problem indicated in KB80188 ("VMFS-6 heap memory exhaustion on vSphere 7.0 ESXi hosts"). Not having the possibility to upgrade to later versions where the problem has been fixed. So, to solve the problem, I created a small script that checks the VMFS-6 volumes mounted and executes the workaround indicated in the KB.

Solution

Disclaimer: Use it at your own risk.

The workaround is to create Eager zeroed thick disk on all of the mounted VMFS6 datastores and then delete it.
Below the script:

# Author: Lorenzo Moglie (ver.1.1 04.04.2022)
#
# VMFS-6 heap memory exhaustion on vSphere 7.0 ESXi hosts (80188)
# https://kb.vmware.com/s/article/80188
# filename: kb80188.sh
#
# WARNING : Use the script at your own risk
#

esxcli storage filesystem list | while read -r LINE; do
TYPE=`echo $LINE | awk -e '{print $5}'`
if [ $TYPE == "VMFS-6" ]; then
 VOLUME=`echo $LINE | awk -e '{print $1}'`
 vmkfstools -c 10M -d eagerzeroedthick $VOLUME/eztDisk`hostname`
 esxcli system syslog mark --message="KB80188 - Created disk  $VOLUME/eztDisk`hostname`"
 vmkfstools -U $VOLUME/eztDisk`hostname`;  echo "Deleted."
 esxcli system syslog mark --message="KB80188 - Deleted disk  $VOLUME/eztDisk`hostname`"
fi
done

Workaround has to be done for each datastore on each host.

So I suggest to copy it on each ESXi hosts root and scheduling it in the cron of the host. This because If you copy it on a shared datastore may not work properly on every hosts. A great explanation written by Mike Da Costa of how to schedule tasks in cron on esxi can be found here.

For example

1. Copy the workaround script into the environment. (In my case /kb81088.sh)
2. Give the script executable permissions
   chmod +x /kb81088.sh
3. On each hosts, edit /var/spool/cron/crontabs/root
4. Add the line to the above file, to schedule the execution every 5 hours
   0 */5 * * * /kb81088.sh
5. Now, we need to kill the crond PID.
   First, get the crond PID (process identifier) by running the command "cat /var/run/crond.pid"
6. Next, kill the crond PID. Be sure to change the PID number to what you obtained in the previous step.
   Example running the command "kill 2098332"
7. Once the process is stopped, you can use BusyBox to launch it again, running the command "/usr/lib/vmware/busybox/bin/busybox crond" to restart crond process

That's it.

VMware NSX for vSphere 6.4.7 not more available to download

Issue
Today I found out, by performing a compatibility check between the various versions of ESXi and NSX to upgrade a customer's farm, that NSX 6.4.7 version due to a serious bug has been removed from download in favor of 6.4.8 (release notes).

" What's New in NSX Data Center for vSphere 6.4.8
VMware NSX for vSphere 6.4.8 resolves a specific issue identified in VMware NSX for vSphere 6.4.7, which could affect both new NSX customers as well as customers upgrading from previous versions of NSX. See Resolved Issues for more information. ”

As you can see from the images below, version 6.4.7 is no longer present from the download ....

... and from the interoperability matrix tables as well.

Solution
It is a good idea to upgrade VMware NSX Data Center for vsphere to version 6.4.8 at least.

That's it.

PowerShell script to retrieve information on VM

Problema
Recentemente mi è capitato di dover recuperare velocemente tramite script PowerShell alcune informazioni come:

1. Nome Virtual Machine (Inventario vCenter)
2. Sistema Operativo
3. Indirizzo IP
4. Nome host della VM (FQDN)
5. Indirizzo MAC

per le Virtual Machine presenti in un determinato Datacenter.

Soluzione
Di seguito lo script in powershell per fare questo.

Connect-VIServer -Server <VCSA> -User <Userrname> -Password <Password>
$DTC = "<Datacenter>"

$Report = @()
ForEach ($VM in (Get-Datacenter $DTC) | Get-VM) {
 $tempvm=@{}
 $tempvm.Name = $VM.Name
 $tempvm.GuestOS = If (!$VM.Guest.OSFullName) {"Tools Not Running\Unknown"} Else {$VM.Guest.OSFullName}
 $tempvm.IP = If (!$VM.Guest.IPAddress[0]) {"Tools Not Running\Unknown"} Else {$VM.Guest.IPAddress[0]}
 $tempvm.FullName = If (!$VM.Guest.hostname) {"Tools Not Running\Unknown"} Else {$VM.Guest.hostname}
 $tempvm.MacAddress = (Get-NetworkAdapter -VM $VM.Name).MacAddress
 #$tempvm.CustomFields = $VM.CustomFields
 $temp = New-Object -TypeName PSObject -Property $tempvm
 $Report += $temp
} 
$Report | Select Name, GuestOS, IP, FullName, MacAddress |  Sort Name | Format-Table -AutoSize #Output on Screen
#$Report | Select Name, GuestOS, IP, FullName, MacAddress |  Sort Name | export-csv ".\Export-VMInfo.csv" #Output on file

Come possibile vedere dallo script sopra, l'output viene mostrato in formato tabella direttamente a video, ma può anche essere esportato e salvato in un file .CSV.

That's it!

PowerCli to configure and modify Syslog on Hosts ESXi - "update"

Qualche tempo fa ho scritto un post sul come configurare/modificare tramite powercli l'entry syslog degli host ESXi.
Tuttavia l'output che si ottiene non permette di verificare a quale host ESXi si riferisce la configurazione. Modificando gli script nel seguente modo possiamo ottenere il seguente risultato:

Ottenere Informazioni (attuali impostazioni)

foreach ($ESXi in Get-VMHost) {
 Get-AdvancedSetting -Name "Syslog.global.logHost" -Entity $ESXi.Name | Select @{L='Host';E={$ESXi.Name}}, Value
} Format-Table -AutoSize

Impostare syslog

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 | Select @{L='Host';E={$ESXi.Name}}, Value
} Format-Table -AutoSize

That's it!

Unconventional way to use HOL

Essendo il mio Home Lab "temporarily out of service" ... mi avvalgo dell'utilizzo degli HOL.
Tutti conosciamo gli "Hands-on Labs" di VMware, sono dei laboratori pre configurati che VMware mette a disposizione degli utenti per testare/verificare ed/o imparare le nuove funzionalità introdotte nei propri prodotti. Seguendo la guida passo-passo si viene guitati nell'utilizzo di tali funzionalità.
Tuttavia non sempre ci sono laboratori pronti per testare tutto ciò che vogliamo. Nel mio caso avevo la necessità di testare le nuove Cmdlets messe a disposizione per SRM PowerCLI descritte in questo sito. Non disponendo di un LAB pre-configurato ad-hoc, ho trovato ricercato un il LAB (HOL-1905-01-SDC - VMware Site Recovery Manager - Data Center Migration and Disaster Recovery) dove è possibile scoprire ed imparare tutto quello che c'è da sapere su VMware Site Recovery Manager (SRM) 8.1.

Effettuato l'accesso al laboratorio, vado a creare la stessa struttura file scaricata dal sito (semplicemente dei file vuoti). Come mostrato nella seguente immagine.

Trasferisco tramite il bottone "INVIA TESTO" i file inviando il testo copiato dal file originale.

Utilizziamo il NOTEPAD (o qualsiasi applicazione che gestisce i file TXT), per editare i file precedentemente creati ed accettare lo streaming di testo che stiamo per inviare .... copiamo il testo del file che vogliamo trasferire, lo incolliamo nell'apposito box "INVIARE UN TESTO ALLA CONSOLE" e premiamo "INVIA" (come mostrato sotto). Attendiamo che tutto il testo sia stato copiato remotamente (questa attività potrebbe richiedere un pò di tempo dipende dalla velocità della connessione) salviamo il file.

Ripetiamo la stessa operazione per il file successivo, fino a quando non abbiamo terminato di trasferire tutti i file necessari.

Possiamo editare i file anche con "Windows PowerShell ISE"

Apriamo la PowerSwhell ed importiamo il modulo
PS C:\> Import-Module -Name C:\LM\Meadowcroft.Srm.psd1
.... provvediamo ad inserire le credenziali lanciando il comando
$creential = Get-Credential

Possiamo lanciare il comando di connessione all'SRM.
PS C:\> Connect-SrmServer -Credential $credential -RemoteCredential $credential

Stabilita la connessione lanciamo il comando oggetto di questo test: "la possibilità di gestire l'orchestrazione/l'attivazione del Plan SRM di attivazione del Disaster Recovery via PowerCLI".
Get-SrmRecoveryPlan -Name "Instruction to Site Recovery Manager" | Start-SrmRecoveryPlan -RecoveryMode Test

Come possibile vedere dalla successiva Immagine, abbiamo attivato il disaster Recovery Plan di SRM via PowerCLI.

Questo è tutto. Abbiamo visto un modo diverso di utilizzare gli Hands-On-Lab di VMware.

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!!

ESXi PSOD - Crash ME

Spesso mi capita di dover eseguire o simulare per dei test di collaudo il failure di un host ESXi. Il metodo più semplice per verificare se si è correttamente configurato l'HA è di simulare il crash di un host con il seguente comando:

# vsish -e set /reliability/crashMe/Panic 1

... in questo modo abbiamo anche la possibilità di verificare il servizio di DUMP.

vSphere Web Client fails: RSL Error #2032

Problema
Il presentarsi del seguente messaggio di errore, post aggiornamento del vCenter Server dalla versione 6.5U2 alla versione 6.7U1, penso sia stato semplicemente casuale. Poteva benissimo presentarsi in qualsiasi altra situazione.

RSL vsphere-client/locales/rsl/tiwo-6.1.0.swf failed to load. Error #2032

Soluzione
Da una veloce ricerca su google, la KB 2092120 sembra fare al nostro caso anche se il file flash della KB è diverso dal mio messaggio di errore. Procedo come indicato nella KB con la cancellazione della cache del browser e riprovo ad accedere nuovamente.

Funziona!!

VMware Advanced Deploy vSphere 6.5 Exam 2018. Certification Unlocked

Il tanto atteso risultato è finalmente arrivato... dopo aver aspettato per circa 6 settimane nell'inbox è arrivata la seguente email .....

Ed il risultato è .......PASSED

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 :-)

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.

LUN ID 256 missing on VMware

Problema
Creato una nuova LUN con ID 256 da Pure Storage e mappata all'Host Group degli Host VMware, non viene vista VMware. La versione degli host ESXi sono 6.5.

Di seguito si vede la nuova LUN Vol07 (ID 256) aggiunta all'host group.

Effettuato il rescan dell'HBA lato VMware, la LUN non appare nella lista di quelle raggiungibili/disponibili.

Ho quindi verificato nel configuration maximum di VMware se presenti dei limiti per la 6.5. Con sorpresa scopro che il limite per il LUN ID è 16383 (vedi immagine sotto - pag.13 del documento indicato in precedenza).

Soluzione
Il problema è stato risolto come anche indicato da Cody Hosterman andando ad associare alla LUN un ID inferiore al 256 (nel mio caso era disponibile il 246).

Quindi procediamo per step:

Rimuovere la LUN dall'Host Group.

Ri-Assegnare la LUN all'Host Group, questa volta sostituendo la dicitura "automatic" con il valore desiderato. Nel mio caso LUN ID 246 e confermando l'operazione premendo sul bottone "Confirm"

Accedere all'Host ESXi effettuare il Rescan delle LUN e verificare che la LLUN sia presente in lista (come possiamo vedere sotto)

vim-cmd: Working With Snapshot

Problema
Di recente ho avuto la necessità di effettuare una "cold" snapshot del vCenter (versione 5.5) senza disporre del client vSphere. 

Soluzione
La soluzione è connettersi al nodo ESXi ed utilizzare la CLI. Prima di tutto verificare su quale nodo  sta girando la VM da spegnere (in questo caso il vCenter) ed accertarsi che il servizio SSH sia attivo.

Connettersi in SSH all'Host e prendere confidenza con il comando "vim-cmd" .

Per iniziare, otteniamo la lista delle Virtual Machine che girano sull'host ESXi filtrando per la VM che vogliamo trovare (in questo caso il vCenter 01).

~ # vim-cmd vmsvc/getallvms|grep -i vc01

In questo modo possiamo ottenere il VMID che identifica la nostra VM, da poter utilizzare successivamente.

Il successivo comando da lanciare è "vim-cmd vmsvc/snapshot.get <VMID>" per verificare se ci sono già delle snapshot attive e successivamente il "vim-cmd vmsvc/power.shutdown <VMID>" per spegnere la VM. 

Per verificare lo stato della VM; e verificare che si è spenta lanciare "vim-cmd vmsvc/power.getstate <VMID>"

Dato che, la VM è nello stato "Powered off" posso lanciare il comando per ottenere la snapshot nel seguente modo  "vim-cmd vmsvc/snapshot.create <VMID> <Snapshot-Name>". 

Esempio:

~ # vim-cmd vmsvc/snapshost.create 31 Pre-Migration2-VCSA 
Create Snapshot:
~ # vim-cmd vmsvc/snapshot.get 31

Di seguito l'output del comando e la catena delle snapshot associate alla VM. Nel nostro caso quella appena creata. 

 Problema risolto. Possiamo far ripartire il vCenter con lo stesso comando "vim-cmd" e verificarne lo stato come di seguito:

~ # vim-cmd vmsvc/power.on 31 
Powering on VM:
~ # vim-cmd vmsvc/power.getstate 31
........

NOTA: Un breve tutorial sulle opzioni e sull'utilizzo del comando "vim-cmd" sono disponibili al seguente link.