Kategorie-Archiv: VMware

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.

Beim Versuch, eine auf einem Datastore gespeicherte ISO-Datei anzuhängen, schlägt der Vorgang mit dem folgenden Fehler fehl:

Der Steuerungsvorgang für die Verbindung ist für die Festplatte „sata0:0“ fehlgeschlagen.

Lösung

Das Problem ist zum Glück schnell gelöst:

• VM abschalten, an die die ISO angehängt werden soll. Die Anpassung ist (leider) nicht im laufenden Betrieb möglich.
• vSphere Client öffnen > VM bearbeiten
• Das CD-Laufwerk aufklappen
• Den Gerätemodus auf „Passthrough-CD-ROM“ umstellen
• VM wieder starten

Jetzt kann man auch wieder fehlerfrei ISOs einlegen.

Wir haben auch schon VMs gesehen, wo das CD-Laufwerk nicht änderbar war (ausgegraut). In solchen Fällen haben wir das Laufwerk einfach entfernt und ein neues wieder hinzugefügt …

In der vCenter Server Appliance (VCSA) und/oder dem vSphere GUI wird diese Fehlermeldung angezeigt:

Die STS-Signaturzertifikate laufen demnächst ab

Wenn man die VSCA rebootet, wird der Dienst vmware-vpxd nicht mehr gestartet. Jede erneute Anmeldung am vSphere-Client funktioniert mit diesem Fehler nicht mehr:

HTTP-Status 400 – Bad Request Message BadRequest
Signaturzertifikat ist ungültig

In /var/log/vmware/vpxd-svcs/vpxd-svcs.log gibt es Einträge wie diesen:

com.vmware.vim.sso.client.impl.SecurityTokenServiceImpl$RequestResponseProcessor opId=] Server rejected the provided time range. Cause:ns0:InvalidTimeRange: The token authority rejected an issue request for TimePeriod

Lösung

Dieses Problem tritt auf, wenn das Security Token Service (STS)-Zertifikat abgelaufen ist. Das führt dazu, dass interne Dienste keine gültigen Tokens mehr erwerben können und nicht mehr funktionieren. Wenn das STS-Zertifikat abläuft, geschieht das auch gerne mal ohne Vorwarnung (8.0.2.400+ fixt das wohl).

Es gibt von vmware einen guten Fix, der leider aktuell in der Broadcom-Umstellung nicht erreichbar ist. Hier ist der Mirror 🙂

1. fixsts.sh (Hier als ZIP) herunterladen
2. Auf der VCSA als root anmelden. Wenn das nicht mehr funktionieren sollte (Timeout und/oder Verbindungsabbruch), einfach als „[email protected]“ anmelden, die shell mit shell.set --enabled true einschalten und eine rootshell via sudo /bin/bash starten.
3. Das Script fixsts.sh in /tmp ablegen und ausführbar machen:
   chmod +x /tmp/fixsts.sh
4. Das Script ausführen:
   /tmp/fixsts.sh
5. Das Script generiert neue STS-Zertifikate und tauscht diese aus. Der Vergang braucht nicht lange. Danach muss man nur noch die vCenter Dienste neu starten:
   service-control --stop --all && service-control --start --all

Alle paar Jahre (alle 10 Jahre spätestens) läuft das selbsterstellt SSL-Zertifikat eines ESXi Hosts ab. Ein vCenter Server kümmert sich in „normalen“ Umgebungen automatisch um die Erneuerung, ein Standalone-Host alleine tut das aber nicht. Läuft das Zertifkat ab, erhält man die altbekannte Browser-Warnung und einen gelben Warnhinweis im ESXi vSphere Host-Client. Im Browser ist das nur halb so schlimm, weil man ja „trotzdem fortfahren“ kann.

Etwas perfide ist das, weil „plötzlich“ alle möglichen Remote-Aufgaben fehlschlagen. PowerShell, esxcli, Perl oder andere Scripts brechen überraschend mit einem „certificate verify failed“ Fehler ab.

Diese Anleitung ist unter ESXi 7.x entstanden, gilt im wesentlichen aber auch für ESXi 8.

Neues Self-Signed Zertifikat auf einem ESXi Host erstellen/aktivieren

1. SSH auf dem ESXi starten (Verwalten > Dienste > TSM-SSH > starten)
2. Als root via ssh auf den ESXi Host anmelden
3. Ausführen:
   /sbin/generate-certificates
   ℹ️unter anderen Patch-Ständen hat das Script auch mal einen Unterstrich im Namen:
   /sbin/generate_certificates
4. Wenn dabei kein Fehler passiert (passiert so gut wie nie), kann man danach den Hostclient (Host-Agent) einfach neu starten. Dazu auf der Shell ausführen:
   /etc/init.d/hostd restart

Das dauert je nach Hardware und Last einen Moment, führt aber zu keinen VM-Ausfällen. Ein ESXi Reboot ist nicht nötig. Wenn der Neustart der Hostdienste fertig ist, ist das neue Zertifikat sofort wieder online.

ACHTUNG: Das alte Browserfestern sollte man natürlich schliessen, denn dessen SSL-Verbindung ist ja nicht mehr gültig. Ja genau, hat einen Facepalm nach drei Minuten Kopfkratzen gekostet 🤦😅

ACHTUNG: Wenn man Veeam als Host-Sicherung im Einsatz hat, muss man da nach einem Host-Rescan das Zertifika auch „neu“ akzeptieren. Sonst läuft die sicherung nicht durch …