Mit vSphere7 kamen grundlegende Veränderungen im Aufbau des ESXi Bootmediums. Eine starre Partitionsstruktur musste einer flexibleren Partitionierung weichen. Dazu später mehr.
Mit vSphere 7 Update 3 kam auch eine schlechte Nachricht für alle, die USB- oder SDCard-Flashmedien als Bootdevice nutzen. Steigende Lese- und Schreibaktivität führte zu schneller Alterung und Ausfall dieser Medien, da sie für ein solches Lastprofil nie ausgelegt waren. VMware hat diese Medien auf die Rote Liste gesetzt und der vSphere Client wirft Warnmeldungen, sollte ein soches Medium noch verwendet werden. Wir werden uns ansehen, wie man USB- oder SDCard-Bootmedien ersetzen kann.
ESXi Bootmedium: Gestern und heute
In der Vergangenheit bis Version 6.x war das Bootmedium relativ statisch. War der Bootvorgang erst einmal abgeschlossen, so war das Medium nicht mehr wichtig. Es gab allenfalls eine gelegentliche Leseanfrage einer VM auf das VM-Tools Verzeichnis. Selbst ein Medium, das im laufenden Betrieb kaputt ging, beeinträchtigte den ESXi Host nicht. Problematisch wurde nur ein Neustart. So konnte man beispielsweise auch bei defektem Bootmedium noch die aktuelle ESXi Konfiguration sichern.
Aufbau des Bootmediums bis ESXi 6.7
Der Aufbau war im Prinzip fast immer gleich: Ein Bootloader von 4 MB Größe (FAT16), gefolgt von zwei Bootbänken mit je 250 MB. Diese enthalten die komprimierten Kernelmodule, die beim Systemstart entpackt und ins RAM geladen werden. Eine zweite Bootbank ermöglicht ein Rollback im Falle eines fehlgeschlagenen Updates. Es folgt eine “Diagnostic Partition” von 110 MB für kleine Coredumps im Falle eines PSOD. Die Locker oder Store Partition enthält z.B. ISO Images mit VM-Tools für alle unterstützten Gast-OS. Von hier aus werden VM-Tools ins die Gast VM eingebunden. Eine häufige Fehlerquelle bei der Tools Installation war ein beschädigtes oder verlorenes Locker Verzeichnis.
Die folgenden Partitionen unterscheiden sich je nach Größe und Art des Bootmediums. Die zweite Diagnostic-Partition von 2,5 GB wurde nur angelegt, wenn das Bootmedium mindestens 3,4 GB groß ist (4MB + 250MB + 250MB + 110MB + 286MB = 900MB). Zusammen mit den 2,5 GB der zweiten Diagnostic Partition erfordert das 3,4 GB.
Eine 4 GB Scratch Partition wurde nur auf Medien mit mindestens 8,5 GB angelegt. Sie enthält Informationen für den VMware Support. Alles darüber hinaus wurde als VMFS-Datenspeicher bereitgestellt. Scatch und VMFS Partition wurden jedoch nur angelegt, wenn das Medium kein USB-Flash oder SDCard Speicher war. In diesem Fall wurde die Scratchpartition im RAM des Hosts angelegt. Mit der Folge, dass bei einem Host Crash auch alle für den Support wertvollen Informationen verloren gingen.
Aufbau des Bootmedium ab ESXi 7
Das oben skizzierte Layout machte die Verwendung großer Module oder Fremdanbietermodule schwierig. Folglich musste das Design des Bootmedium grundlegend verändert werden.
Zunächst wurde die Bootpartition von 4 MB auf 100 MB vergrößert. Auch die beiden Bootbänke wurden auf mindestens 500 MB angehoben. Die Größe gestaltet sich flexibel, abhängig von der Gesamtgröße des Mediums. Die beiden Diagnose-Partitionen (Small Core Dump und Large Core Dump), sowie Locker und Scratch wurden zusammengeführt in eine gemeinsame ESX-OSData Partition mit flexibler Größe zwischen 2,9 GB und 128 GB. Übriger Speicherplatz kann optional als VMFS-6 Datenspeicher bereitgestellt werden.
Unterschieden werden bei vSphere 7 vier Größenklassen für Bootmedien:
- 4 GB – 10 GB
- 10 GB – 32 GB
- 32 GB – 128 GB
- > 128 GB
Die oben dargestellten Partitionsgrößen gelten für neu installierte Bootmedien unter ESXi 7.0. Doch wie sieht es für Bootmedien aus, die von Version 6.7 migriert wurden?
Migrierte Altlasten
Dazu schaue ich mir einen Host meines Homelabs an. Er hat ein 16 GB SATA-DOM Bootmedium. Der Hersteller des Mediums ist SuperMicro.
ls /dev/disks -lh | grep SuperMicro
Wir erkennen fünf Partitionen: eine 100 MB Partition, zwei mal 500 MB, sowie 6,3 GB und 7,4 GB. Das passt nicht richtig ins obige Bild. Demnach sollte ein Bootmedium mit 16 GB Kapazität in vier Partitionen zu je einmal 100 MB, zwei mal 1 GB für die Bootbänke, sowie etwa 12,7 GB für OSData aufgeteilt werden.
Aufschluss über das Filesystem erhält man mit dem Befehl:
esxcli storage filesystem list
Neben den beiden (zu kleinen) Bootbänken gibt es noch ein VMFS Volume mit Namen “esx2_local”. Damit liegt die Erklärung auf der Hand. Unter ESXi 6.7 wurde das SATA-DOM (16 GB) auf die alte Art partitioniert:
- 4 MB System Boot
- 250 MB Bootbank 0
- 250 MB Bootbank 1
- 110 MB Small Coredump
- 286 MB Locker
- 2,5 GB Large Coredump
- 4 GB Scratch
Der verbleibende Rest von 7,4 GB wurde als VMFS Partition formatiert. Bei der Migration werden zwar alle Partitionen des Bootmedium gelöscht und neu angelegt, das gilt jedoch nicht für VMFS Datenspeicher. Diese werden nicht angetastet (aus gutem Grund). Folglich stand für die neue Patitionierung nur ein Speicherbereich von weniger als 10 GB bereit. Für diesen Fall werden nur kleine Bootbänke mit je 500 MB angelegt.
Was tun?
Die einzig praktikable Lösung ist, die Konfiguration zu sichern und das Bootmedium neu anzulegen. Der Host ist Teil eines 4-Knoten vSAN Clusters. Damit hier nichts schief geht, versetzen wir den Host in den Wartungsmodus mit der Option “Full data migration“. Damit ist der Host absolut leer. Den lokalen VMFS Datenspeicher esx02_local löschen wir über den vSphere Client.
Sicherung der Konfiguration
Sobald der Host komplett geleert ist und in den Wartungsmodus gewechselt hat, können wir die Konfiguration über PowerCLI sichern.
Connect-VIserver <hostname>
Get-VMhost | Get-VMHostFirmware -BackupConfiguration -DestinationPath "C:\temp"
Die Konfiguration des Hosts wird im Zielpfad (hier c:\temp) als tgz File abgelegt. Der Dateiname ist configBundle-<fqdn>.tgz. Zum Beispiel configBundle-esx03.lab.local.tgz
Es ist notwendig, den Host komplett neu zu formatieren. Dazu verwenden wir ein ESXi Bootimage, welches dem Patchlevel des Hosts am nähesten kommt. Im dargestellten Fall ist der zu formatierende Host auf ESXi 7 Update 3. Daher verwenden wir auch das offizielle VMware ESXi Bootmedium (ISO) in Version 7U3. (Anmerkung: Das verwendete Image 7U3 wurde zwar von VMware zurückgezogen, funktioniert jedoch in meinem Lab problemlos und beseitigte einige Probleme.)
Setup ESXi
Das ISO wird über iPMI / iLO / iDRAC bereitgestellt und über das jeweilige Bootmenü gestartet. Der nun folgende Abschnitt entspricht einer Neuinstalltion eines ESXi Servers. Die Schritte sind nur der Vollständigkeit wegen dargestellt.
EULA komplett durchlesen, ausdrucken, einrahmen, an die Wand hängen und mit F11 quittieren.
Das ESXi Setup erkennt richtig, dass zwei der drei im Host vorhandenen Medien bereits von vSAN beansprucht werden. Das lokale SATA-DOM “SuperMicro SSD” ist als Installationsziel richtig vorausgewählt.
Mit F1 erhalten wir zusätzliche Informationen zum gewählten Medium. Es befindet sich darauf bereits eine (alte) ESXi Installation, die wir jedoch verändern möchten und daher neu formatieren müssen.
Anb dieser Stelle ist es in unserem Fall wichtig, die Option Install und nicht Upgrade zu verwenden, denn wir wollen eine Neupartitionierung erreichen.
Das jetzt gewählte Passwort muss nicht mit dem ursprünglichen übereinstimmen. Es ist nur für eine temporäre Verwendung.
Vor der Installation müssen wir nochmals bestätigen, dass wir das Medium überschreiben wollen.
Vor dem Reboot muss das Medium über iPMI ausgehängt werden, damit der Host beim Neustart in die neue Installation bootet.
Der frisch installierte ESXi Server erhielt hier über DHCP eine IP Adresse. Falls kein DHCP Server verfügbar ist, so muss dem Host im DCUI eine temporäre IP Adresse zugeteilt werden.
Die einzige Konfiguration dieses Hosts ist das Management Netzwerk mit IP Adresse und Gateway (DHCP), sowie ein Passwort für den root User. Dies genügt jedoch für den nächsten Schritt. Dazu verbinden wir uns mit PowerCLI auf die temporäre Management Adresse des Hosts.
Connect-VIserver <Host IP>
Wir verwenden das root Kennwort, das wir beim Setup vergeben haben.
Bevor wir die ursprüngliche Konfiguration wiederherstellen können, müssen wir den Host in den Wartungsmodus versetzen.
Set-VMHost -VMHost 192.168.1.72 -State "Maintenance"
Optional: Installation weiterer VIBs
Sollten neben dem reinen ESXi weitere Kerneldienste auf dem ESXi aktiv gewesen sein und dafür zusätzliche VIBs notwendig sein, so sind diese jetzt zu installieren. Besonders wichtig ist dies bei der Verwendung von NSX-T. Wird hier ein Restore gemacht, ohne vorherige Installation der NSX-T VIBs, so scheitert der Restore und der Host wird nicht administrierbar.
Restore der Konfiguration
Wenn alle zusätzlichen VIBs installiert sind (falls notwendig), so kann jetzt mit dem Restore begonnen werden.
Set-VMHostFirmware -VMHost 192.168.1.72 -Restore -SourcePath "c:\temp\2021-11-23\configBundle-esx02.lab.local.tgz"
Der Befehl erfordert zunächst einen Login des root Users.
Direkt nach dem Login wird die Konfiguration eingespielt und ohne Rückfrage ein Reboot ausgelöst.
Der Host erhält nach dem Neustart die ursprüngliche Konfiguration zurück, inklusive aller Passworte, IP-Adressen, Netzwerkeinstellungen und Object-IDs.