Autoren-Archiv: weed

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.