Wanneer je je VMware host(s) hebt geupgrade naar VMware 6.7 U3 (build 14320388), krijg je hoogstwaarschijnlijk te maken met uitzonderlijk veel Hardware Health Alarms !
In de logging zul je dan meldingen zien zoals deze :
De reden hiervan is een bug in de U3 release.
Zolang er geen oplossing was, is het aan te bevelen niet U3 te installeren maar U2.
Maar VMware heeft afgelopen november een patch uitgebracht die dit oplost.
In dit VMware Artikel is te lezen wat de symptomen zijn.
Het is erg belangrijk om de beschikbare patch te installeren aangezien er zoveel meldingen gegenereerd kunnen worden dat de vCenter Server Database zodanig groeit (SEAT partitie) dat de vCenter Server kapot zal gaan.
Oplossing :
De oplossing is het installeren van Patch ESXi670-201911001
Dit kan als je een VMware Cluster hebt zonder downtime via de vSphere Update Manager.
Maar als je maar 1 ESX Host hebt, zul je downtime in moeten plannen aangezien de Host moet rebooten na de installatie van de patch.
Controleer eerst of inderdaad de patch nog niet geinstalleerd is :
In een VMware Cluster kun je gewoon de update uitrollen waarbij VMware alles vanzelf regelt.
Dit kan dus gewoon onder werktijd !
Heb je maar 1 host, dan is de vSphere Update Manager geen optie (tenzij je een fysieke vCenter hebt) en je moet downtime inplannen i.v.m. rebooten van de server.
Het installeren van de patch gaat handmatig via de SSH shell.
Zet de SSH service op de host aan en verbind naar de server met bijvoorbeeld Putty.
Download de ESXi670-201911001 patch en upload deze naar de locale VMware Datastore van de ESX Host.
In Putty blader je nu naar de locatie van de patch.
Zorg nu wel eerst dat alle actieve VM’s worden afgesloten.
Zet dan de ESX host in Maintenance Mode
Gebruik nu het volgende commando om de patch te installeren :
esxcli software vib update -d /vmfs/volumes/datastore3/ISO/ESXi670-201911001.zip
VMware gaat nu aan de slag en je zult een hoop info voorbij zien komen :
Als het installeren klaar is moet de ESX host gereboot worden. Als dat gebeurd is is VMware bijgewerkt naar de juiste build (15018017) en zullen de vele Hardware Health Alarms verleden tijd zijn.
Workaround :
Is het niet mogelijk om meteen de patch te installeren omdat de omgeving niet down kan ?
Dan bestaat er ook een workaround die het loggen stopt waardoor je vCenter geen gevaar meer loopt.
Log via SSH in op de betreffende host.
Gebruik dan het volgende commando om de WBEM services uit te schakelen :
esxcli system wbem set –enable false
Wanneer er 3rd party providers aanwezig zijn, dan zal bij elke reboot de WBEM services weer ingeschakeld worden.
Dit kan ook uitgeschakeld worden door de SFCBD watchdog uit te schakelen in chkconfig :
chkconfig sfcbd-watchdog off
Dit geeft je wat tijd om downtime in te plannen zodat je alsnog de patch kunt installeren.
Loopt je vCenter al gevaarlijk vol ?
Dit stukje is uitsluitend op eigen risico uit te voeren !
Zorg dat je een goede backup of snapshot van je vCenter hebt aangezien we hieronder de vCenter database gaan opruimen/truncaten !!!!
Aangezien zo goed als alle vCenters als VCSA uitgerold worden/zijn, behandelen we hieronder dan ook alleen de VCSA.
Login op de VCSA via Putty
typ dan :
shell
Je komt nu op de BASH Shell terecht.
Nu moet je verbinding maken met de VCDB door het volgende commando te gebruiken :
/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres
Om de top 20 grootste tabellen te laten zien :
/opt/vmware/vpostgres/current/bin/vacuumdb -d VCDB -U postgres -f -e -v -t
SELECT nspname || ‘.’ || relname AS “relation”, pg_size_pretty(pg_total_relation_size(C.oid)) AS “total_size”
FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT IN (‘pg_catalog’, ‘information_schema’)
AND C.relkind <> ‘i’
AND nspname !~ ‘^pg_toast’
ORDER BY pg_total_relation_size(C.oid) DESC
LIMIT 20;
Je krijgt dan een Top 20 lijst met de grootste tabellen.
Gebruik dan het volgende commando om tabellen te truncaten :
TRUNCATE table <tablename>;
Voordat je bovenstaande uitvoert, is het aan te raden dit VMware Artikel te bestuderen !