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

vSwitch Wiederherstellung mit dem CLI

Virtuelle Distributed-Switches (vDS) haben zahlreiche Vorteile gegenüber Standard vSwitches. Durch die zentrale Verwaltung und einheitliche Konfiguration über alle Hosts, ist weniger Raum für Konfigurationsfehler im Vergleich zu Standard vSwitches. Nennt mich altmodisch, aber ich habe dennoch gerne das Management Interface des Hosts an einem klassischen Standard vSwitch. Wenn irgendetwas dummes passiert kann man dann immer noch den Host erreichen und Änderungen vornehmen.

Kürzlich ist der Host eines Kunden ausgefallen. Nach der Wiederherstellung und Rückspielung der Konfiguration war die Nummerierung der vmnics aus noch nicht geklärter Ursache vertauscht. Der Host war daher weder über vCenter, noch über Hostclient ansprechbar. Der Kunde hatte nicht genügend vmnics im Host und konfigurierte daher das Management Network über eine Portgruppe auf dem vDS. Das ist erlaubt und in der Regel kein Problem. In diesem speziellen Fall war es jedoch durchaus ein Problem. Ich war im wörtlichen Sinn vom Host ausgesperrt. Normalerweise könnte man über das Direct Console User Interface (DCUI) die Zuordnung der vmnics zum Management Netzwerk neu organisieren. Das funktionierte jedoch nicht, da alle vmnics von Distributed vSwitches beansprucht waren. Sie konnten daher keinem Standard vSwitch und somit auch nicht dem Management Kernelport zugeordnet werden.

Was nun?

Es gibt einen Ausweg aus dieser Lage. Dazu muss man Zugang zum CLI des DCUI haben. Über eine lokal angeschlossene KVM-Konsole, ILO oder iRMC kann man sich auf dem Host anmelden und wählt im Hauptmenü “Troubleshooting Options”.

„vSwitch Wiederherstellung mit dem CLI“ weiterlesen

ESXi nach Upgrade zurücksetzen

ESXi Host nach einem Upgrade mittels DCUI auf Letzte Version zurücksetzen

ESXi Host-Upgrades bergen immer ein gewisses Risiko. So kann es während des Upgradevorgangs zu Problemen kommen, dass der Host nicht mehr optimal funktioniert. In solchen Fällen ist es gut zu wissen, daß man zum letzten funktionsfähigen Image zurückkehren kann.

Ein Rücksprung ist nach den folgenden Upgrademethoden möglich:

  • Installation oder Deinstallation eines VIB
  • Installation mittels Update Manager
  • Entfernung eines Host-Profils
  • Installation vom ISO

„ESXi nach Upgrade zurücksetzen“ weiterlesen

ESXi root Password Recovery

Warum es wichtig ist, den physischen Zugang zum Server und zu IPMI / iRMC zu sichern

Der Titel des Artikels ist nicht ganz korrekt, denn bei der beschriebenen Technik handelt es sich nicht wirklich um ein Recovery, sondern um ein Passwort Rücksetzung auf ein leeres Passwort des root Kontos. Eine detaillierte Anleitung schrieb Autor Lingeswaran auf Unixarena, die ich an einem Testsystem ausprobierte. Der Ablauf ist im Artikel unten dokumentiert.

Schwachstelle ?

Ich würde diese Möglichkeit nicht als Schwachstelle oder Sicherheitslücke von VMware ESXi betrachten, denn man benötigt zur Durchführung physischen Zugang zum Server bzw. zu dessen Remotekonsole (iRMC). Dass ein Rechenzentrum entsprechend gesichert sein muss, versteht sich im Grunde von selbst. Aber auch Remote Management Konsolen müssen geschützt sein und vor allem Defaultpasswörter müssen geändert werden. Für die unten beschriebene Prozedur benötigte ich keinen Zutritt zum Rechenzentrum. Alles wurde remote mittels iRMC durchgeführt. Das gilt auch für das virtuell eingelgte Ubuntu ISO. „ESXi root Password Recovery“ weiterlesen