NSX ESX Agent Manager (EAM) bleibt auf starting stehen

Nach dem STS-Zertifikatswechsel hatte noch der NSX-Manager sein leiden damit.

Nach dem Wechsel vom STS-Zertifikat und dem lösen der nicht angepassten Einträge im LookupService hatte ich noch ein Thema, dass im vRealize Operations der NSX-Connector nicht wieder verbunden werden konnte, es folgte folgender Fehler:

javax.net.ssl.SSLHandshakeException: com.vmware.vim.vmomi.client.exception.VlsiCertificateException: Server certificate chain is not trusted and thumbprint doesn't match.

Der NSX-Manager hatte ich nicht im Verdacht, da keine Rückmeldungen von Kundenseite oder Support kam, dass z.B. keine Virtual Wire angelegt werden konnten oder ähnliches.

Der VMware Support war bei der ersten Session auch ein wenig ratlos und gab das weiter an das Engineering. In der Zwischenzeit haben wir uns dann an die Arbeit gemacht, ein paar hundert Server durch den Lifecycle zu schicken. Das war auch genau die Aktion, welche es gebraucht hatte.

Die Server wurden alle sauber durchinstalliert, aber beim verschieben in einen NSX-aktivierten Cluster wurde der NSX-Agent schlicht nicht installiert. Da war mal klar, mit dem NSX-Manager stimmt noch mal irgendwas nicht. Aber es war nicht der NSX-Manager, sondern der ESX Agent Manager (EAM) war mit Status gelb auf Starting.

Das führte mich dann zu folgendem KB-Artikel:

https://kb.vmware.com/s/article/2112577#update_extension_certificate_on_vcenter_server_appliance

Ein kurzer Blick in die eam.log bestätigte auch das Verhalten:

cat /var/log/vmware/eam/eam.log
2020-11-09T13:42:32.488Z |  INFO | vim-monitor | VcConnection.java | 640 | Connecting to https://vcenter.domain.local:8089/sdk/vimService via vCenter proxy http://localhost:80
2020-11-09T13:42:36.532Z | ERROR | vim-monitor | VcConnection.java | 213 | Failed to login to vCenter as extension. vCenter has probably not loaded the EAM extension.xml yet.: Cannot complete login due to an incorrect user name or password.

Als dann im Artikel noch folgendes Modul erwähnt war: com.vmware.vim.vmomi wusste ich, dass dies auch mit meinem Problem in vROps zusammenhängen muss. Da hier die gleiche Schnittstelle einen Fehler geworfen hatte.

Das erneuern des Zertis ging recht einfach zur Hand, direkt auf dem vCenter in der Shell, aber denk bitte daran, zuerst einen Snapshot zu machen:

mkdir /certificate

/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store vpxd-extension --alias vpxd-extension --output /certificate/vpxd-extension.crt
/usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store vpxd-extension --alias vpxd-extension --output /certificate/vpxd-extension.key

python /usr/lib/vmware-vpx/scripts/updateExtensionCertInVC.py -e com.vmware.vim.eam -c /certificate/vpxd-extension.crt -k /certificate/vpxd-extension.key -s vcenter.domain.local -u Administrator@vsphere.local

rm -drf /certificate

service-control --stop vmware-eam
service-control --start vmware-eam

Danach dauert es eine Weile, bis die Änderungen durchs System sind. Der EAM Status wechselt auf grün, das vCenter versucht überall den NSX-Agent frisch zu installieren, dass ist aber ganz normal und ein gutes Zeichen.

Anschliessend klappts auch wieder mit dem NSX-Connector vom vROps.

Leave a Reply

Your email address will not be published. Required fields are marked *