vmWare vSphere ESXi Host: „Das diesem Host zugewiesene Zertifikat ist abgelaufen. Sie müssen ein gültiges Zertifikat installieren.“

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 …

vSphere ESXi Host „(vim.fault.InvalidState)“ und/oder „The operation is not allowed in the current state.“

Eine Meldung wie diese kann auf einem ESXi so aussehen:

(vim.fault.InvalidState) {
   faultCause = (vmodl.MethodFault) null,
   faultMessage = <unset>
   msg = "Received SOAP response fault from [<<io_obj p:0x000000899beea2b8, h:5, <TCP '127.0.0.1 : 37600'>, <TCP '127.0.0.1 : 8307                                       '>>, /sdk>]: restoreConfiguration
The operation is not allowed in the current state."
}

Lösung

Meistens versucht der Admin da grade etwas, das im aktuellen Zustand wirklich nicht erlaubt ist. Zum Beipiel ein Backup der Konfiguration wiederherzustellen.

Es reicht in der Regel aus, den Host in den Wartungsmodus zu versetzen. An der Shell geht das mit:

vim-cmd hostsvc/maintenance_mode_enter

vmWare vSphere ESXi Host Konfiguration Backup/Restore/Migrate

In letzter Zeit müssen wir einige ESXi Hosts von USB-Sticks oder SD-Karten auf eine lokale boot-SSD (oder HDD, je nach Kundenwun$ch) umziehen. Das geht natürlich weder im laufenden Betrieb noch automatisch – man braucht eine Neuinstallation. Am einfachsten sichert man also die Konfiguration des vSphere ESXi Hosts, installiert schnell „sauber“ neu und stellt selbige Konfiguration wieder her.

ESXi von USB/SD Migration

  1. Backup der Konfiguration
  2. Host neu installieren
    • ⚠️ Die gleiche Version verwenden! ein Umzug von 7.x zu 8.x geht meistens schief, vor allem wenn man mehrere Netzwerke und/oder Storagedapter hat. Im Zweifel erst migrieren, dann updaten. vmWare empfiehlt zwar auch noch den gleichen Build, aber mit (leicht) unterschiedlichen Buildnummern hatten wir bisher noch keine Schwierigkeiten.
  3. Restore der Konfiguration

ESXi Konfiguration sichern (Backup)

SSH auf dem Host einschalten. Je nachdem via vSphere Host Client (Verwalten > Dienste > TSM-SSH > Starten) oder im vCenter (Host > Konfiguration > Dienste > SSH).

Als nächstes als root via SSH auf dem Hosts anmelden und diese beiden Zeilen ausführen:

# Volatile Konfiguration synchronisieren
vim-cmd hostsvc/firmware/sync_config

# Backup erstellen, Download-URL erhalten
vim-cmd hostsvc/firmware/backup_config

Die Backup-Datei dann herunterladen (configBundle-HOSTNAME.tgz). Von der angegebenen URL einfach direkt via HTTP(s) herunterladen. Das Sternchen (*) in der URL ist der Hostname oder die IP des Hosts.

ESXi Konfiguration widerherstellen (Restore)

Ein Restore-Vorgang klappt nur wenn:

  • Der Host die selbe Version hat, wie das Backup (z.B. v7.0.3)
  • Der Host im Wartungsmodus ist
  • Das Management-Network erreichbar ist

Dann geht das schnell und einfach:

  1. SSH einschalten
  2. Via SCP die Konfigurationdatei (configBundle-HOSTNAME.tgz) auf den Host nach /tmp/ hochladen
  3. Die Konfigurationdatei umbenennen zu configBundle.tgz
  4. Konfiguration widerherstellen
# Restore der Konfiguration starten
vim-cmd hostsvc/firmware/restore_config 0

Der Host bootet nach dem Restore SOFORT neu. Aber nach dem Neustart ist fdann auch schon alles sofort wieder „wie vorher“.

Keine Panik: Der Host startet ungefragt neu

Veeam: Failed to prepare guest for hot backup. Details: VSSControl: -2147467259 [0x8004231f].

Veeam gibt diese Warnung in einem Backup-Job aus:

Failed to prepare guest for hot backup. Details: VSSControl: -2147467259 Backup job failed.
Cannot create a shadow copy of the volumes containing writer's data.
VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x8004231f].  

Lösung

Der Fehlercode 0x8004231f steht für „VSS_E_INSUFFICIENT_STORAGE“ oder auch „nicht genügend Speicherplatz für die Schattenkopie“. Die Festplatte ist voll.

Schattenspeicherplatz wird für die Systemwiederherstellungspunkte von Veeam Backup & Recovery verwendet, wenn „Appication Image Aware Processing“ eingeschaltet ist (was auch empfohne ist).

Der Fehler tritt auf wenn die Festplatte tatsächlich voll ist. Das kann zum Beispiel ungewollt passieren, wenn man der 100Mbyte großen Windows „EFI-Systempartition“ oder der (möglicherweise eingerichteten) „Widerherstellungspartition“ einen Laufwerksbuchstaben gegeben hat. Naturgemäß haben diese Partitionen praktisch keinen freien Speicherplatz. „Voll“ bedeutet hier, „nicht genug Platz für eine Volumenschattenkopie“. Bei Maschinen mit viel Arbeitsspeicherbedarf, zum Beispiel ERP-Systeme oder SQL-Server, kann das plötzlich sehr viel sein. Wir haben einen SQL-Server VSS Dump „mal eben“ 20Gbyte schreiben sehen.

Upgrade VMware vCenter 8.0 bleibt bei 80% stehen „Waiting for RPM installation to start. This may take several minutes …“

Problem

Das Upgrade auf vCenter 8.0 bleibt manchmal „kommentarlos“ bei 80% stehen und bewegt sich nicht mehr. Auch nach einiger Zeit nicht. Die neue Appliance wurde aber erfolgreich installiert und botet (scheinbar) auch fehlerfrei.

„Waiting for RPM installation to start. This may take several minutes“ 80%

Man kann die neue virtuelle vCenter-Appliance aber im Inventar sehen, pingen und auch die Konsole öffnen.

Lösung

Was die Ursache für diesen Effekt ist, wissen wir auch nicht genau. Aber man kann die Installation und Datenmigration problemlos über die VCSA-Oberfläche der „neuen“ vCenter-Instanz fortsetzen. Man öffne:

https://<temporäre-vcenter-adresse>:5480

und melde sich mit dem „frisch „alten“ root-Kennwort dort an.

Die zugehörige (temporär) IP-Adresse zeigt die Konsole ja an.

Der vCenter Screen zeigt die Appliance-IP

Wenn man dem Assistent dann dort weiter folgt, läuft das Setup (in aller Regel) problemlos durch.