ESXi Bootmedium – Neuerungen in v7 und Altlasten aus v6.x

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 eines ESXi Bootmediums vor Version 7

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.

Veränderung des Partitionslayouts zwischen Version 6.x und 7.x

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
Dynamische Partitionierung unter vSphere 7 in Anhängigkeit von der Medienkapazität.

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?

„ESXi Bootmedium – Neuerungen in v7 und Altlasten aus v6.x“ weiterlesen

ESXi Konfigurations-Restore scheitert mit leerer DCUI Seite

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.

„ESXi Konfigurations-Restore scheitert mit leerer DCUI Seite“ weiterlesen

PowerCLI offline Installation

In vielen Firmenumgebungen sind strikte Sicherheitsrichtlinien in Kraft. Damit ist es nur eingeschränkt, oder überhaupt nicht möglich auf Internet Resourcen zurückzugreifen. Das bemerkt man beispielsweise, wenn man versucht PowerCLI auf einem Management System zu installieren. Zwar bietet die Verfügbarkeit der PowerCLI Module in der Powershell Gallery eine einfache Methode der Installation, oder des Updates, jedoch nur wenn der Zugriff zu dieser externen Ressource von Powershell erlaubt ist. Die Verwendung der Powershell Gallery erfordert den NuGet Packet Management Provider. Auch dieser muss online bezogen werden.

 Install-Module -Name VMware.PowerCLI -Scope CurrentUser 

Ist die Internetverbindung eingeschränkt, oder blockiert, so scheitert obiger Befehl. Doch man kann die Module auch offline übertragen. Dazu benötigt man einen PC mit freiem Internetzugang. Hier verwendet man nun einen anderen Befehl, der die Module nicht installiert, sondern nur in einen definierten Pfad herunter lädt.

 Save-Module -Name VMware.PowerCLI -Path C:\temp\PSModules

Den gesamten Inhalt des Ordners PSModules kopiert man auf ein Speichermedium der Wahl (z.B. USB Flashmedium) und überträgt die Dateien zum gewünschten Offlinesystem, auf dem PowerCLI benötigt wird.

Wenn man auf dem Zielsystem über Adminrechte verfügt, können die Module in folgenden Pfad kopiert werden.

 C:\Program Files\WindowsPowerShell\Modules 

Jetzt sind die PowerCLI Module auch auf dem Offlinesystem verfügbar. Für ein Versionsupdate muss die Prozedur wiederholt werden. Es ist ratsam, die VMware Module zuvor zu entfernen, bevor man die aktuellen überträgt.

Get-Module VMware.* -ListAvailable | Uninstall-Module -Force

Weitere Anpassungen

Customer Experience Improvement Program (CEIP)

Das VMware Customer Experience Improvement Program sammelt Daten über die Verwendung von VMware Produkten. Dem kann man entweder zustimmen (true), oder es ablehnen (false). Für Offlinesysteme ist nur die Ablehnung (false) sinnvoll. Der unten dargestellte Befehl unterdrückt zukünftige Nachfragen innerhalb der PowerCLI.

Set-PowerCLIConfiguration -Scope AllUsers -ParticipateInCeip $false -confirm:$false

Ungültige SSL Zertifikate ignorieren

Bei Verwendung selbstsignierter Zertifikate im vCenter verweigert PowerCLI die Verbindung. Dieses Verhalten kann unterdrückt werden mit dem Befehl:

Set-PowerCLIConfiguration -Scope AllUsers -InvalidCertificateAction Ignore -confirm:$false

PowerCLI Fehler – Invalid server certificate

Auf Systemen mit frisch aufgesetzter PowerCLI passiert es mir immer wieder, dass meine Skripte mit Fehler beendet werden, oder dass schon der Befehl Connect-VIServer scheitert.

Connect-VIServer Error: Invalid server certificate. Use Set-PowerCLIConfiguration to set the value for the InvalidCertificateAction option to Prompt if you’d like to connect once or to add a permanent exception for this server

Das Problem lässt sich schnell und dauerhaft umgehen.

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false