So konnte man bei einer Installation auf einem USB-Stick bereits mit 5 GB Platz auskommen. Nur wenn das Boot-Medium eine SAS-Platte war, legte der Installer zusätzlich eine VMFS-Partition für virtuelle Maschinen an, sofern auf dem Laufwerk noch nicht zugeordneter Festplattenplatz vorhanden war.

Allerdings war es auch bei ESXi 6.x schon so, dass der Installer auf USB- und SD-Geräten wegen deren I/O-Empfindlichkeit nur eine Locker-Partition für die VMware Tools und Core-Dump-Dateien erstellte, aber keine Scratch-Partition anlegte.

Embedded versus Installed Mode

In einem solchen Fall befand sich die /scratch-Partition in einer RAM-Disk, die unter /tmp eingebunden war. Installierte man also ESXi auf einem USB- oder SD-Device führte das stets zum so genannten Embedded Mode.

Nur wenn man ESXi auf einer Festplatte (oder iSCSI/SAN/FCoE-Partition) mit einer Größe von mindestens 5 GB installierte, lief ESXi am Ende im Installed Mode mit entsprechender Persistenz.

Mit dem Kommando

esxcfg-info -e

lässt sich der Typ der ESXi-Installation ermitteln. Das Ergebnis konnte dann sein:

• visor-thin thin weist auf eine installierbare Bereitstellung hin
• visor-usb weist auf eine eingebettete Bereitstellung hin
• visor-pxe zeigt eine PXE-Bereitstellung an

Neues Layout für ESXi 7

Das Setup von ESXi 7 beschreibt das Boot-Medium stets mit einer GPT-Partitions­tabelle, bestehend aus vier (Embedded) bzw. fünf Partitionen (Installable). Das neue Layout konsolidiert die ursprüng­lichen Partitionen small-core-dump, large-core-dump, locker und scratch zur neuen ESX-OSData-Partition vom Typ VMFS-L.

Das gilt nicht nur für die Neuinstallation von ESXi, sondern wirkt sich auch auf ein ESXi-Upgrade aus. Dabei wird das Startgerät neu partitioniert und die genannten Partitionen des ESXi 6.x-Hosts werden in das neue ESX-OSData-Volume überführt.

Für die Konsolidierung der Partitionen bei einer Neuinstallation bzw. einem Upgrade gilt dann:

• Ist kein benutzer­definiertes Core-Dump-Ziel konfiguriert, ist der Core-Dump-Speicherort per Default eine Datei im ESX-OSData-Volume.
• Hat der Syslog-Dienst Protokolldaten vorher auf der 4GB VFAT-Scratch-Partition abgelegt, dann landen diese nach dem Upgrade unter var/run/log auf das ESX-OSData-Volume migriert.
• VMware Tools werden von der Locker-Partition migriert, und diese wird gelöscht.
• Die Core-Dump-Partition wird ebenfalls gelöscht.

Dabei variieren je nach Größe des Installations­mediums auch die für die Boot-Bank-Partitionen verwen­deten Größen, wie folgende Tabelle zeigt.

Installationsoptionen für ESXi 7

Bei einer Neu­installation von ESXi 7 stehen Admins somit drei Möglichkeiten offen (abgesehen von Auto Deploy):

• Möchte man weiterhin von einem USB- oder SD-Gerät booten, muss dieses über 8 GB Speicher verfügen. Zusätzlich braucht man dann für die neue OSData-Partition eine lokale Festplatte (SSD, NVM2) mit mindestens 32 GB.
• Nutzt man als Installations­medium nur eine lokale Festplatte mit mindestens 32 GB, dann enthält diese die Start­partitionen und das ESX-OSData-Volume.
• Hat die lokale Festplatte mehr als 138 GB, wird auf dieser noch zusätzlich eine VMFS-Partition für VMs angelegt.

Da Version 7.0 die Installation auf SD-Cards noch unterstützt, befindet sich die Scratch-Partition bei einem SD-Gerät ohne zusätzlichen Speicher für persistente Daten nach wie vor auf einer RAM-Disk unter /tmp. ESXi 7.0 arbeitet dann im so genannten herabgestuften Modus.

Dabei zeigt ESXi eine solche Systemwarnung an:

„WARNUNG: Kein dauerhafter Speicher für Systemprotokolle und Daten verfügbar. ESX wird mit begrenztem Speicherplatz im System ausgeführt, Protokolle und Systemdaten gehen beim Neustart verloren.“

Ein anderer möglicher Nebeneffekt des herabgestuften Modus ist ein langsamer Start aufgrund der Zeit, die für die Neuerstellung des Festplatten­zustands vergeht. Außerdem muss man dann zwingend ein SD-Flash-Gerät verwenden, das vom Anbieter für das jeweilige Server-Modell genehmigt wurde.

vSphere 7 Update 3

In den Release Notes für das Update 3 weist VMware darauf hin, SD-Karten als Boot-Medien in Zukunft überhaupt nicht mehr zu unterstützen und ausschließlich auf SSDs zu setzen.

Bei VMware ist man sich darüber im Klaren, dass Kunden für die ESXi-Installation deshalb SD-Karten oder USB-Geräte verwenden, weil sie Geräteschächte freihalten (etwa für vSAN-Devices) und die Kosten für die Installation von ESXi-Hosts senken möchten.

Solche Geräte haben jedoch eine geringere Lebensdauer und Zuverlässigkeit, so dass sich Probleme im Laufe der Betriebszeit häufen. Zudem leiden SD-Karten und USB-Laufwerke oft an geringer Leistung, weil sie keine hoch­frequenten Lese-/Schreibvorgänge tolerieren.

Bei SSD/Flash bestehen Probleme solcher Art nicht. So unterliegt NAND-Flash-Speicher im Laufe der Zeit beim Schreiben zwar einer Art Verschleiß, jedoch verfügen Flash-Geräte, die für höhere I/Os ausgelegt über Methoden, um mit dieser Art von Abnutzung umzugehen (Defekt-Management).

SSD- oder NVMe-Laufwerke verwenden Methoden für das so genannte „Wear-Leveling“, um die Schreib­vorgänge gleichmäßig über das gesamte Laufwerk zu verteilen. Zudem haben Laufwerke dieser Art stets eine Reserve­kapazität, sodass eine Speicherzelle nahtlos ersetzt werden kann, wenn sie verschlissen ist.

Da es eine solche ausgefeilte Logik bei SD-Karten und USB-Sticks nicht gibt, lehnt VMware das Verwenden von SD- und USB-Laufwerken als Boot-Medien in Zukunft also ganz ab. Momentan erhält man bei Verwenden von SD- und USB-Medien aber nur die oben beschriebene Warnung, dass sich das Startvolume in einem degradierten Modus befindet.