Kategorie-Archiv: VMware

Manchmal begrüßt das vCenter den Admin mit einer eher rätselhaften „Zertifikatsstatus“ Fehlermeldung im vCenter UI. In diesem speziellen Fall war eine alte rootCA, die durch die Jahre der Datenmigration irgendwie noch vorhanden war. Es ist auch gar nicht so einfach, diese endlich loszuwerden.

Lösung

Zuerst muss man das betroffene Zertifikat finden. Es wäre natürlich viel zu hilfreich, wenn das UI das direkt anzeigen würde, daher muss man etwas tiefer gehen.

Die erste Anlaufstelle dazu ist der Zertifikatsmanager im vCenter unter Einstellungen > Verwaltung > Zertifikatsverwaltung. In diesem Fall hatten wir Glück, das abgelaufene „Vertrauenswürdige Stammzertifizierungsstellen“ Zertifikat war in der Liste enthalten. Das ist aber nicht immer der Fall, davon nicht entmutigen lassen.

Sollte das nicht funktionieren, kann man sich alle Zertifikate des vCenter Stores mit diesem Einzeiler an der Shell anzeigen lassen:

for i in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list); do echo STORE $i; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $i --text | egrep "Alias|Not After"; done

Im zweiten Schritt holen wir uns die (dezimale) Seriennummer des Zertifikates. Die UI zeigt die Nummer an, wenn man das betroffene Zertifikat auseinanderfaltet. Selbige Seriennummer rechnen wir schnell in hexadezimal um, weil alle anderen Tools die Seriennummer nur als hex-Wert angeben (*seufz*).

Also in diesem Fall:

10582953812961080800 = 92:DE:34:6C:07:E9:35:E0

Mit der Seriennummer bewaffnet, können wir uns an der Shell die „echten“ Zertifikatsdetails heraussuchen. Die Liste der Zertifikate bekommt man mit („q“ um less zu beenden):

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | less

ℹ️ Es können auch mehrere Zertifikate entfernt werden. Alle abgelaufenen (und nicht verwendeten) Zertifikate sollten sogar entfernt werden, um diese zertifikatsbezogenen Alarme zu entfernen.

Aus dieser Liste brauchen wir eigentlich nur Alias und den X509v3 Subject Key Identifier:

Jetzt brauchen wir von diesem Zertifikat wiederum den Thumbprint (vmware nennt das die „CN(id)“). Man nehme also nun den Fingerabdruck von dem CN, der abgelaufen gewesen ist. Die Fingerabdrücke listet man auf mit:

/usr/lib/vmware-vmafd/bin/dir-cli trustedcert list

Mit dem Thumbprint kann man nun endlich das Zertifikates exportieren und möglicherweise sogar ein Backup wegspeichern. Sicher ist sicher.

/usr/lib/vmware-vmafd/bin/dir-cli trustedcert get --id <THUMBPRINT> --login [email protected] --outcert /tmp/ABGELAUFENES-CERT.cer

Die Meldung „Certificate retrieved successfully“ bestätigt, dass das geklappt hat.

Wenn der Export vorliegt, kann man nun endlich das Zertifikat „Un-Publishen“:

/usr/lib/vmware-vmafd/bin/dir-cli trustedcert unpublish --cert /tmp/ABGELAUFENES-CERT.cer

Die Meldung „Certificate unpublished successfully“ bestätigt, dass das geklappt hat.

Jetzt kann man das Zertifikat auch endlich aus dem Endpoint-Zertifikatsseicher (VECS, VMware Endpoint Certificate Store) löschen:

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <ALIAS>

Zu guter Letzt wird jetzt noch der Zertifikatsspeicher refreshed. Das sorgt für einen saubere Replikation, wenn man mehrere PSCs im Einsatz hat:

/usr/lib/vmware-vmafd/bin/vecs-cli force-refresh

… und wenige GUI-Minuten später ist auch schon die Zertifikatsstatus-Fehlermeldung dauerhaft entfernbar.

Manchmal kommt es vor, dass eine VM „überraschend“ nicht mehr migriert werden will. Die VM wurde aber schon mal migriert, vMotion ist lizenziert (meint: korrekt eingerichtet), andere VMs migrieren auch, nur diese eine hat die Option im Menü grau („ausgegraut„). Es laufen auch keine Jobs mehr, die die Migration verhindern können. Also keine andere (Storage/vmotion-) Migration, kein Backup oder andere Replikationsaufgaben.

Wie passiert das?

Das Problem kann auftreten, wenn eine Sicherungs- oder Storage-Motion-Vorgang einer VM zwar abgeschlossen ist, aber und die Einträge in der (PostgreSQL-) Tabelle aus dem vCenter Server nicht entfernt wurden. Das kann auch mal passieren, wenn Backup-Ende und vCenter-Reboot unglücklich zusammenfallen.

Wer das genau warum gewesen ist und wer noch betroffen ist, kann man in der Datenbank zum Glück schnell nachschauen. Auf der Shell des vCenter Servers gibt dieses Statement die entsprechende Liste für alle Objekte aus:

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres -c "select * from vpx_disabled_methods;"

Lösung

Wie bekommt man jetzt die Migrieren-Funktion zurück?

1. Man besorge sich die MO-ID („Managed Object“) ID der VM. Entweder aus dem MOB-Browser (https://VCENTER.EXAMPLE.COM/mob) oder direkt aus der URL vom vCenter GUI. Die URL enthält die MO-ID, wenn man im vCenter zu dem betreffenden Objekt navigiert und den Parameter „VirtualMachine:vm-1234568“ kopiert.

2. Man öffne das VM Ops Manager Interface unter:

https://VCENTER.EXAMPLE.COM/mob/?moid=AuthorizationManager&method=enableMethods

3. In selbigen fügt man oben („entity“) für „MOID“ die MO-ID (aus Schritt 1) ein und in der Mitte („method“) die Methode zum reversen des Feldes für „RelocateVM_Task“. Also genau dieses XML:

Oben („entity“)

<!-- array start -->
<entity type="ManagedEntity" xsi:type="ManagedObjectReference">vm-12345678</entity>
<!-- array end -->

Mitte („method“)

<Methode>RelocateVM_Task</Methode>

4. Unten rechts „Invoke Method“ führt die Methode aus und setzt die Felder zurück.

Der Erfolgsbericht folgt auch sofort, in maschinenlesbarer Form. Ein „Refresh“ im vCenter danach offenbart auch sofort die vermisste „Migrieren“ Funktion wieder.

Vor ein paar Tagen hatten wir Probleme mit der Anmeldung beim vCenter Appliance Management Interface („VAMI“). Statt der Dienste-Gui sehen wir nur die Fehlermeldung

Unable to authenticate user

Das Passwort für den Root-Benutzer war ganz sicher war. Die Verbindung via SSH funktioniert problemlos.

Lösung

Der Dienst „applmgmt“ ist vermutlich abgestürzt. Der Dienst kann aber an der Shell neu gestartet werden und ist praktisch sofort wieder verfügbar.

1. Als root (oder [email protected]) via SSH einloggen und mit shell die Shell starten. Sollte die Shell nicht freiwillig wollen, lässt sich diese mit shell.set --enabled true einschalten und danach starten.
2. Den Dienst starten:
   service-control --start applmgmt

Und schon geht das GUI wieder.

Sollte das wider erwartend nicht funktionieren oder in einer Fehlermeldung enden, loht eventuell ein Blick auf https://knowledge.broadcom.com/external/article?legacyId=68149

Das Upgrade auf den neuen vCenter Server 8.0.3 („U3“) bleibt gerne mal mit diesem Fehler stehen:

Pre-install failed for vmidentity:Expand

Das Logfile in /var/log/vmware/applmgmt/Patchrunner.log verrät auch ein paar mehr Details:

vmidentity:Expand INFO vmidentity Found ssoserver cert in TRUSTED_ROOTS, This will be deleted from store
vmidentity:Expand INFO vmidentity.utils Deleting cert from TRUSTED_ROOTS VECS store
vmidentity:Expand ERROR vmidentity.utils Failed to execute command '['/usr/lib/vmware-vmafd/bin/dir-cli', 'trustedcert', 'unpublish', '--cert', '/storage/seat/software-updateub8jty50/stage/scripts/patches/payload/components-script/vmidentity/<Cert_filename.pem>', '--login', '<VC FQDN>']'
vmidentity:Expand ERROR vmidentity.utils dir-cli failed. Error 1168: Operation failed with error ERROR_NOT_FOUND (1168)

Lösung

Es gibt da noch eine Bug im Update-Setup, das das Zertifikat „ssoserver“ nicht aus dem Certificate-Store gelöscht bekommt. Aber man kann das einfach manuell machen und das Setup danach fortsetzen.

1. Alias des „ssoserver“ Zertifikates besorgen (Die Zahlenkette hinter der Bezeichnung „Alias“)
   /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'
2. Das falsche Zertifikat löschen („<ALIAS>“ durch die Zeichenkette von 1. ersetzen)
   /usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <ALIAS> -y

Danach kann man das Setup mit einem Klick auf „resume“ fortsetzen.