Die Sicherung und Wiederherstellung der ESXi Host-Konfiguration ist eine Standardprozedur die bei Wartungsarbeiten am Host eingesetzt werden kann. Gesichert werden nicht nur Hostname, IP Adresse und Passwörter, sondern auch NIC und vSwitch Konfiguration, Object ID und viele weitere Eigenschaften. Selbst nach einer kompletten Neuinstallation eines Hosts kann dieser wieder alle Eigenschaften der ursprünglichen Installation annehmen.
Kürzlich wollte ich im Homelab die Bootdisk eines Hosts neu formatieren und musste herfür ESXi neu installieren. Der Neustart mit der frischen Installation funktionierte problemlos und der Host bezog eine neue IP über DHCP.
Nun sollte über PowerCLI die ursprüngliche Konfiguration wiederhergestellt werden. Dazu versetzt man zunächst den Host in den Wartungsmodus.
Set-VMhost -VMhost <Host-IP> -State "Maintenance"
Die zuvor gesicherte Konfiguration kann nun wiederhergestellt werden.
Set-VMHostFirmware -VMHost <Host-IP> -Restore -Sourcepath <Pfad_zum_Konfigfile>
Der Befehl fordert einen root Login an und macht danach automatisch einen Reboot. Am Ende des Bootvorgangs begrüßte mich eine leere DCUI.
Ich konnte mich zwar einloggen (mit dem ursprünglichen Passwort), jedoch waren sämtliche Netzwerkverbindungen verschwunden. Auch die Konfiguration des Management-Netzwerks war nicht auswählbar (grau). Der Host war blind und taub.
Über die Troubleshooting-Options konnte ich die ESXi-Shell aktivieren. Der Wechsel dorthin erfolgt mit [Alt]+[F1]. Zunächst prüfte ich die physischen NICs.
esxcli network nic list
Alle NICs waren vorhanden und im Zustand “up”.
Im nächsten Schritt prüfte ich die vSwitches. Das ursprüngliche System hatte Standard-vSwitches und Distributed-vSwitches.
esxcli network vswitch standard list
Keine Ergebnisse.
esxcli network vswitch dvs vmware list
Keine Ergebnisse.
Offensichtlich hatte der Host nach Restore der Konfiguration alle vSwitches verloren. Damit auch alle Kernelports, Portgruppen und Einstellungen. Der Host war Teil eines 4-Node vSAN-Clusters und meine Ambitionen, diesen “from scratch” neu zu konfigurieren hielten sich in Grenzen.
Versuch mit alternativer Konfiguration
Ich habe es mir zur Standardprozedur gemacht, vor jedem Upgrade der Hosts deren Konfiguration zu sichern. Vielleicht gab es ein Problem mit der aktuellsten Konfiguration oder dem aktuellsten ESXi ISO. Somit hatte ich auch ältere Konfigurationen von ESXi 7 U3, oder ESXi 7 U2a zur Verfügung. Leider war das Ergebnis immer das gleiche. Eine leere DCUI. In letzter Not griff ich auf eine über ein Jahr alte Sicherung zurück. Diese war auf Basis von ESXi 7 U1 (Build 16850804). Ich besorgte mir das passende ISO und versuchte erneut den Restore. Dieses Mal mit Erfolg!
Was war anders?
Dass eine Konfiguration defekt ist, könnte man noch verstehen. Dass aber alle Konfigurationen des letzten Jahrs beschädigt sein sollen, ist extrem wenig wahrscheinlich. Die Frage die sich mir aufdrängte war nun, warum der Restore mit der alten U1 Konfiguration funktionierte und alle neueren nicht. Mir fiel auf, dass ich damals im Lab noch kein NSX-T bereitgestellt hatte. Das brachte mich auf die Spur.
Wenn wir ein Standard ESXi Image installieren, dann enthält dieses keine NSX Kernelmodule. Das kann man überprüfen mit folgendem Kommando:
esxcli software vib list | grep nsx
Bei einer Standardinstallation liefert der Befehl keine Ergebnisse. Ein konfigurierter NSX-T Transport-Node liefert dagegen zahlreiche Treffer.
Spätestens hier ist mir der Groschen gefallen. Dem Host fehlten schlicht die NSX-T Kernelmodule, die in der Konfiguration referenziert sind und der Restore endet als ESXi-Zombie.
Der korrekte Ablauf
Vor dem Restore der Konfiguration müssen dem Host die fehlenden NSX-T Kernelmodule bereitgestellt werden. Dies funktioniert normalerweise automatisch wenn der Host im NSX-manager für NSX Konfiguriert wird (System > Fabric > Nodes > Host Transport Nodes > Managed by vCenter > Configure NSX). Das funktioniert aber nicht, da unser Host noch nicht seine Konfiguration hat und vom vSphere-Cluster getrennt ist. Ein Henne-Ei Problem.
NSX-T Kernelmodule laden und installieren
Glücklicherweise kann man die Module aber auch manuell bereitstellen. Dazu lädt man bei VMware unter “Networking & Security” > “NSX-T Datacenter” > “Go to Downloads” das Paket “NSX Kernel Module for VMware ESXi 7.0” herunter. Wichtig!: Es muss das zur NSX-T Installation passende Paket ausgewählt werden.
Wer beispielsweise NSX-T Version 3.1.3.1 betreibt, muss auch genau das dazu passende Paket laden (Select Version). Das Paket lautet nsx-lcp-<Version><build>-esx70.zip. Der Host sollte sich im Wartungsmodus befinden und der SSH Dienst muss aktiviert sein. Das Paket kann über SCP transferiert werden.
scp <sourcepath> root@<esx>:<destinationpath>
Hier am Beispiel meiner Umgebung. Das nsx-lcp Paket wird ins /tmp Verzeichnis des ESXi Hosts übertragen.
scp E:\install\vmware\NSX-T\nsx-lcp-3.1.3.1.0.18504670-esx70.zip root@esx02.lab.local:/tmp/
Über SSH Client können wir das Setup auf der Shell starten.
esxcli software vib install -d /tmp/nsx-lcp-3.1.3.1.0.18504670-esx70.zip
Nach Eingabe des Kommandos passiert zunächst einige Sekunden gar nichts auf der Shell. Das Setup läuft jedoch im Hintergrund. Abwarten und Kaffee trinken!
Nach der Installation der NSX-T Module sollte zunächst ein Reboot durchgeführt werden, bevor die Konfiguration wieder eingespielt wird.
Anmerkung: Ich hatte im Beispiel oben zunächst das falsche Paket geladen mit einer Version, die etwas über meiner NSX-T Version lag (3.1.3.3 anstatt 3.1.3.1). Der NSX-T-Manager wollte damit nicht arbeiten. Daher ist die Richtige Auswahl wichtig. Ein Downgrade der Pakete ist einfach und geht über den gleichen Befehl wie oben. Dabei werden Pakete ggf. ersetzt.
Konfiguration Restore
Sobald die NSX-T Kernel Module installiert sind kann die Original Konfiguration wiederhergestellt werden.
Nach dem Reboot ist der Host noch vom Cluster getrennt, kann aber durch ein einfaches Connection > Connect wieder verbunden werden.
Fazit
Rückblickend ist die Lösung ziemlich offensichtlich und einfach. Aber dieses Problem hat mich fast in den Wahnsinn getrieben. Ich habe noch nie eine leere DCUI erlebt. Aber anstatt den Host von Grund auf neu zu konfigurieren, habe ich es auf die vExpert-Art gemacht. Testen, reproduzieren, analysieren und hoffentlich eine Erklärung für das Phänomen finden… und die Lösung mit der Community teilen.