ESXi Bootmedium – Neue Anforderungen in v8

Die Anforderungen an ESXi Bootmedien haben sich mit ESXi v7 Update3 grundlegend gewandelt. Die Partitionierung wurde verändert und auch die Anforderungen an die Belastbarkeit des Mediums waren gestiegen. Ich hatte darüber in meinem Blogartikel “ESXi Bootmedium – Neuerungen in v7” berichtet.

USB-Bootmedien erwiesen sich als nicht robust genug und wurden daher ab v7U3 nicht mehr unterstützt. Es ist zwar immer noch möglich, ESXi auf ein USB-Medium zu installieren, jedoch muss dann die ESX-OSData Partition auf einen dauerhaften Speicher umgeleitet werden.

Achtung! USB-Medien und SD-Karten sollten nicht für produktive ESXi Installationen verwendet werden!

Erlaubte Ziele für die ESXi Installation

SD-Karten und USB-Medien scheiden als Installationsziel wegen ihrer schlechten Write-Endurance aus. Weiterhin erlaubt und empfohlen sind dagegen magnetische Disks, SSD und SATA-DOM (Disk-on-Module).

SATA-DOM auf Supermicro E300-9D

Neue Anforderungen ab ESXi v8

Mein Homelab lief bisher unter vSAN 7 und damit unter der klassischen OSA-Architektur. Um den Cluster unter der neuen vSAN ESA Architektur zu betreiben, brauchte es vSphere 8 und neue Speichergeräte.

Ich habe die Installation und Hardware-Kompatibilität auf einem 64 GB USB-Medium getestet (nicht empfohlen!). Während der Installation gab es erwartungsgemäße Warnungen bezüglich des USB-Mediums. Dennoch konnte ich erfolgreich die Erkennung der NVMe Devices und das vCenter Deployment testen.

Setup Warnung bei installation auf ein USB-Flashmedium

Nach erfolgreicher Testphase installierte ich ESXi 8U2 auf das SATA-DOM meines Supermicro E300 Servers. Zu meiner Überraschung scheiterte das Setup sehr früh mit der Meldung: “disk device does not support OSDATA“.

RTFM

Die Erklärung hierfür ist simpel: “Read the fine manual!”

Mein 16 GB SATA-DOM von Supermicro war schlicht zu klein.

Der Setup-Guide für ESXi 8 benennt die Anforderungen ganz klar inter dem Punkt “Storage Requirements for ESXi 8.0 Installation or Upgrade“:

For best performance of an ESXi 8.0 installation, use a persistent storage device that is a minimum of 32 GB for boot devices. Upgrading to ESXi 8.0 requires a boot device that is a minimum of 8 GB. When booting from a local disk, SAN or iSCSI LUN, at least a 32 GB disk is required to allow for the creation of system storage volumes, which include a boot partition, boot banks, and a VMFS-L based ESX-OSData volume. The ESX-OSData volume takes on the role of the legacy /scratch partition, locker partition for VMware Tools, and core dump destination.

VMware vSphere product doumentation

Mit anderen Worten: Neuinstallationen benötigen ein Bootmedium von mindestens 32 GB (128 GB empfohlen) und Upgrade von einer ESXi v7 Version benötigt mindestens 8 GB, jedoch muss in dieser Installation die OSData Partition bereits auf einen alternativen Datenträger umgeleitet sein.

Dirty Trick?

Natürlich versuchte ich es mit einem schmutzigen Trick. Ich installierte zunächst erfolgreich ein ESXi 7U3 auf dem 16 GB SATA-DOM und führte danach eine Upgrade Installation auf v8U2 durch. Auch dieser Versuch scheiterte, da in der frischen v7 Installation der OSData Bereich nicht umgeleitet wurde.

Ich möchte keine Installation auf einem USB-Medium durchführen, da ich bereits zu viele Fälle gesehen habe, in denen diese Medien versagt haben. Bleibt eigentlich nur die Investition in ein größeres SATA-DOM.

Ich habe mich für das 64-GB-Modell entschieden, da es ein guter Kompromiss zwischen Mindestanforderungen und Wirtschaftlichkeit ist.

NSX Manager – Wechsel der Zertifikate

Nach der Installation von NSX-T Data Center verwenden die NSX-Manager und der Cluster selbstsignierte Zertifikate. Diese können und sollten durch vertrauenswürdige Zertifikate einer Enterprise-CA ersetzt werden. Die neuen Zertifikate können im UI des NSX-Managers importiert werden. Der Tausch erfolgt jedoch leider ausschließlich über einen API-Call. Dies lässt sich meist angenehm mit Hilfmitteln wie Postman umsetzen. Nun gibt es aber Umgebungen, die sehr restriktiv sind und in denen weder eine Applikation wie Postman zur Verfügung steht, noch sonst ein Linux-System von dem aus man die API-Calls absetzen könnte.

Wir werden hier skizzieren, wie wir dies ohne spezielle Hilsmittel direkt von der NSX-Manager Appliance realisieren können.

„NSX Manager – Wechsel der Zertifikate“ weiterlesen

VeeamON Resiliency Summit 2023

Am 24. Oktober 16:00 CEST findet der VeeamON Resiliency Summit statt, der weltweit live online gestreamt wird. Wir können gespannt sein auf die Vorstellung des Veeam Data Platform 23H2 Updates.

Darüber hinaus gibt es drei Tracks mit Breakout Sessions zu den Themenschwerpunkten Veeam Data Platform, Veeam Platform Extensions und Veeam Partner Ecosystem.

Das Veeam Data Platform 23H2 Update beinhaltet die neuesten Resilienz-Funktionen von Veeam Backup & Replication V12.1, Veeam ONE V12.1 und Veeam Recovery Orchestrator v7, sowie Updates für AWS v7, Azure v6 und Google v5.

Registrierung

Die Registrierung lohnt sich auf jeden Fall, auch dann wenn man den Stream nicht live verfolgen kann, da der Content später auf Abruf verfügbar sein wird.


Tech X 300 in Kopenhagen – Ein Rückblick

Offizielles Shirt der Tech X 300 2023

VMUG Dänemark setzte mit der Tech X 300 neue Standards für regionale VMUG Meetings. Ich sage dies als VMUG Leader und mit großer Anerkennung.

  • 2 Tage
  • 3 Keynotes
  • 36 Sessions
  • 27 Speaker
  • Teilnehmer aus 17 Ländern

Meine dänischen Kollegen haben eine außergewöhnliche gute Veranstaltung auf die Beine gestellt, die einer VMUG UserCon alle Ehre gemacht hätte.

„Tech X 300 in Kopenhagen – Ein Rückblick“ weiterlesen