Hardware-Anforderungen für ESX 9: CPUs, I/O-Geräte, Bootmedien und wie Sie jeden Host prüfen

Was ESX 9 braucht und woran es scheitert

Broadcoms Hardware-Anforderungen für ESX 9.0 und 9.1, aktualisiert am 24. August und am 29. September 2026, setzen dieselbe Untergrenze: einen Server und eine CPU, die für das Release im Broadcom Compatibility Guide (BCG) gelistet sind, einen 64-Bit-x86-Host mit mindestens zwei CPU-Kernen, aktiviertem NX/XD und aktivierter Hardwarevirtualisierung (Intel VT-x oder AMD RVI), 8 GB RAM, einen Gigabit- oder schnelleren Ethernet-Controller und einen persistenten Bootdatenträger mit mindestens 32 GB. Broadcom empfiehlt 12 GB RAM für produktive VMs, ein Bootgerät mit 128 GB für neue Server und UEFI, denn „die Unterstützung für Legacy-BIOS ist eingeschränkt“.

Vier Bedingungen blockieren das Upgrade oder lassen es scheitern: eine für 9.x eingestellte CPU-Serie (der Installer „blockiert oder verhindert die Installation“), ein Bootdatenträger unter 8 GB (das Upgrade „wird blockiert“), ein I/O-Gerät mit Status End of Life, das ESX 9 nicht erkennt, und ein Cluster, der noch mit Baselines verwaltet wird: „Um ein Upgrade auf VCF 9 abzuschließen, müssen alle Cluster“ auf Images umsteigen (KB 424294). Eine fünfte Bedingung entscheidet über den Support: „Hardware, die für VCF 8.x/ESXi 8.0 unterstützt wurde, wird für VCF 9.x/ESXi 9.0 nicht automatisch unterstützt“ (KB 443586). Der Rest ist überwiegend als veraltet eingestuft: heute unterstützt, später entfernt.

CPU-Unterstützung: Veraltet heißt nicht eingestellt

KB 318697 kennt zwei Phasen. Eine veraltete (deprecated) CPU-Serie lässt sich mit CPU_SUPPORT_WARNING installieren, „The CPUs in this host may not be supported in future VCF releases“, und bleibt „während der gesamten Lebensdauer des genannten VCF-Release samt Updates und Patches oder bis zum End-of-General Support (EoGS)“ unterstützt, solange das Servermodell im BCG gelistet bleibt; KB 413002 bestätigt, dass Sie „mit dem Upgrade fortfahren können“. Eine eingestellte (discontinued) Serie wird blockiert.

Skylake-SP hat die Phase gewechselt: KB 428874, aktualisiert am 18. September 2026, unterstützt die Serie jetzt „im Deprecated Mode für VCF 9.x“ auf Servern, die der BCG mit „VCF Supported. Confirm w/ Vendor“ kennzeichnen kann, ohne weitere Treiberverbesserungen, mit Fehlerbehebungen auf Best-Effort-Basis, Hardware- und Firmware-Support beim Serverhersteller, einem Override-Verfahren für Installation und Upgrade und ohne Support „über VCF 9.x hinaus“.

Broadcom KB 318697 (ohne Datum auf der Seite, Stand 4. Oktober 2026) und KB 428874 (aktualisiert am 18. September 2026). Nicht genannte Serien haben keinen Hinweis für 9.x; die Server brauchen trotzdem einen Eintrag im BCG.

I/O-Geräte: Restricted, End of Life und die Liste zu 9.1

KB 391170 teilt veraltete Geräte in zwei Klassen ein. Ein Restricted-Gerät behält einen Treiber und einen BCG-Eintrag mit der Kennzeichnung „Restricted“, erhält keine Treiberverbesserungen, nur Fehlerbehebungen auf Best-Effort-Basis, und „wird im nächsten Major Release entfernt“. Bei einem End-of-Life-Gerät wurde das Gerät oder sein Treiber entfernt: ESX 9.0 beansprucht es nicht (claim), und „wenn Sie ein Upgrade auf ESX 9.0 von einem Host mit einem EOL-Gerät durchführen, können die folgenden nicht behebbaren Folgen eintreten“: der Verlust des Zugriffs auf Datastores, auf das Netzwerk oder auf die Konfiguration des Hosts. Ersetzen Sie diese Geräte zuerst; die Listen sind Tabellendateien im Anhang der KB.

VCF 9.1 stuft weitere Geräte als veraltet ein, zur späteren Entfernung: die Adapter Marvell FastLinQ 57800/57810/57811 und 41000/45000, Cisco VIC 1200 und 1300, AMD Solarflare 8000 und X2 sowie die Atlantic-Treiber von Marvell/Aquantia. Die Support Notes zu 9.1 nennen den 57810 veraltet, während KB 442745 die Karte BCM57810 10Gb Base-T für ESX 9.0 als End of Life führt, mit einem Upgrade, das „fehlschlägt oder zum vollständigen Verlust der Netzwerkverbindung führt“. Identifizieren Sie jeden Adapter anhand der vier PCI-IDs, die vmkchdev -l ausgibt, und suchen Sie im BCG danach (KB 323110), beginnend dort, wohin KB 443586 weist: „I/O-Controller und NVMe-Speichergeräte, da sich die Treiberanforderungen verschoben haben“.

Bootmedien und Systemspeicher

SD- und USB-Geräte bleiben in 9.0 und 9.1 für die Bootbanks unterstützt, doch OSDATA auf ihnen „wird als veraltet eingestuft“: Best Practice ist ein separates, persistentes lokales Gerät mit mindestens 128 GB, und ein auf USB oder SD aktualisierter Host sollte OSDATA auf einem persistenten Datenträger oder einer SAN-LUN erhalten.

VCF 9.1 stuft USB- und SD-Bootgeräte, ESX ohne persistenten Systemspeicher für OSDATA sowie Systemspeicher unter 32 GB als veraltet ein, zur Entfernung im nächsten Major Release. KB 317631 lässt das Booten von USB und SD „über das Produkt-Release VCF 9.0 hinweg, einschließlich der Update-Releases“ zu; ihre Richtlinie, strenger als die Seiten zu den Hardware-Anforderungen, nennt 128 GB, gerechnet in binären Gigabyte, als Minimum für das Bootgerät unter 9.x, mit mindestens 100 MB/s und 128 TBW über fünf Jahre, und Broadcom zertifiziert keine neuen Server mehr, die von USB oder SD booten. Für einen neuen Host erfüllt eine persistente SSD mit mindestens 128 GiB und dieser Schreibfestigkeit alle diese Vorgaben.

Arbeitsspeicher, Firmware-Modus und TPM

ESX 9 braucht 8 GB RAM, abzulesen mit esxcli hardware memory get, und „Intel Optane PMEM wird in ESX 9.0 nicht mehr unterstützt“. Laut KB 313152 hat vSphere 8.0 Legacy-BIOS für neue Plattformen ab Cascade Lake und Rome aufgegeben, und ein aktualisierter Server mit Legacy-BIOS kann „nicht mehr funktionieren“, in der Regel ohne andere Abhilfe als UEFI oder ein Downgrade; die Reihenfolge der KB: auf dem alten Release auf UEFI umstellen, neu starten, Geräteprobleme beheben, dann nur aktualisieren, wenn der Host funktioniert. vsish -e get /hardware/firmwareType zeigt den Modus (KB 436768), und Patches per esxcli bleiben auf 8.0-Hosts im Legacy-Modus bei der Warnung BIOS_FIRMWARE_TYPE stehen, sofern nicht --no-hardware-warning angehängt wird (KB 391610, 414676).

Ein TPM steht nicht auf der Liste der Anforderungen. Für den Einsatz eines TPM verlangt das Sicherheitshandbuch zu vSphere 9.0 ein im UEFI aktiviertes TPM 2.0, UEFI Secure Boot sowie ein TPM, das auf SHA-256 und die Schnittstelle TIS/FIFO eingestellt ist, „nicht CRB“; ESX speichert dann den Schlüssel zur Verschlüsselung seiner Konfiguration im TPM. esxcli hardware trustedboot get zeigt, ob ESX ein TPM erkennt.

Treiber, Firmware und Cluster-Images

vSphere Lifecycle Manager behandelt Firmware als Teil des Cluster-Images, geliefert als Firmware- und Treiber-Add-on aus „einem speziellen Hersteller-Depot, auf dessen Inhalt Sie über ein Softwaremodul namens Hardware Support Manager zugreifen“, das der Hardwarehersteller bereitstellt. „Firmware-Updates sind für Cluster oder Hosts, die Sie mit Baselines verwalten, nicht verfügbar“, und vCenter 9.0 unterstützt keine per Baselines verwalteten Cluster mehr. Für gemischte Hardware gilt: „vLCM-Images für Cluster mit heterogener Hardware werden erst ab ESX 9 unterstützt“ (KB 424294); solche Cluster erreichen ESX 9 deshalb über einen vorübergehend freigegebenen Update Manager und wechseln dann „umgehend“ auf ein Image. In KB 441837 weist das Basis-Image von 9.1 ein für 9.0 gebautes Hersteller-Add-on zurück, bis das 9.1-Add-on des Herstellers importiert ist. Laut den Support Notes zu VCF 9.0 werden „CIM-Provider für ESX 8.x und früher in ESX 9.0 nicht unterstützt“. Für vSAN belässt KB 428874 ReadyNodes mit Cascade Lake und Skylake-SP unter 9.x im Deprecated Mode.

So prüfen Sie jeden Host

Auf jedem 8.x-Host beschreiben esxcli hardware platform get und esxcli hardware cpu list die Plattform und ihre CPUs; esxcli hardware pci list und vmkchdev -l listen PCI-Geräte und ihre IDs auf; esxcli network nic get -n vmnic0 liefert Treiber und Firmware einer Netzwerkkarte; und in esxcli storage core device list zeigt das Bootgerät Is Boot Device: true, seine Größe und Is USB (KB 305267). In vCenter 9.x testet die Hardwarekompatibilitätsprüfung auf Host-Ebene, auf der Registerkarte Updates des Hosts, „Servermodell und I/O-Geräte“ jedes beliebigen Hosts gegen den BCG für die ESX-Version, die Sie wählen, und listet kompatible, inkompatible und unbekannte Geräte auf. Die Prüfung setzt ein aktiviertes Customer Experience Improvement Program und ein vCenter mit Internetverbindung voraus und validiert keine Firmware; unter vCenter 9.1.0.0 scheitern vLCM-Hardwareprüfungen für Hosts mit einer Version vor 8.0 Update 2 (KB 437157). Gegen ein ESX-9-Image markiert eine Compliance-Prüfung des Clusters einen Host als „incompatible“, wenn sich das Image nicht anwenden lässt, und der Pre-Check vor der Remediation ergänzt Health-Checks.

Die genannten Broadcom-KB-Artikel; TechDocs: Hardware-Anforderungen von ESX 9.0 und 9.1, Support Notes zu VCF 9.0 und 9.1, Handbuch zu vSphere Lifecycle Manager 9.0, Stand 4. Oktober 2026.

Für den nächsten Schritt brauchen Sie nur Ihr Inventar: eine Zeile je Host mit Servermodell, CPU-Modell, den PCI-IDs jedes Adapters, Controllers und NVMe-Geräts, Typ und Größe des Bootgeräts, Firmware-Modus und Lifecycle-Modus des Clusters. Abgeglichen mit KB 318697, den Listen aus KB 391170 und dem BCG ist jeder Host bereit, nach einem Bauteil- oder Firmware-Wechsel bereit oder bleibt bis zu seinem Austausch auf 8.x.

Wie lange eine Hardware-Entscheidung für 9.x trägt

Broadcoms VCF-Blog vom 16. Juli 2025 legte seine „allgemeine Erwartung für die Zukunft“ dar: Support für Major Releases „für sechs (6) Jahre ab diesem Major Release“, dazu „in bestimmten Fällen“ ein optionales Jahr Extended Support, „ein geschätztes End-of-Service-Datum am 17. Juni 2031“ für 9.x, ein Major Release alle drei Jahre und Minor Releases etwa alle neun Monate, die ersten voraussichtlich mit 27 Monaten Support, das letzte mit 45. Stand 4. Oktober 2026 haben wir keine Broadcom-Seite mit einem Enddatum für 9.0 oder 9.1 gefunden und auch kein Datum für das nächste Major Release.

Mit diesem Release sollen veraltete CPUs, Restricted-Geräte, das Booten von USB und SD sowie Systemspeicher unter 32 GB wegfallen, die in 9.1 als veraltet eingestuften Adapter mit einem späteren, und KB 428874 rät den Besitzern, „vorauszuplanen“. Hosts, auf denen ESX 9 nicht läuft, können bis zum Supportende von vSphere 8 auf ESXi 8 warten, in einem imagebasiert verwalteten Cluster mit einheitlicher Hardware, wie unser Leitfaden zum Ende des allgemeinen Supports von vSphere 8 darlegt: vCenter 9.0 verwaltet ESX-8.0-Hosts „im selben Cluster mit ESX-9.0-Hosts“ (KB 424129), und vCenter 9.1 nimmt ESXi-8.x-Hosts auf, die mit 8.x-Schlüsseln lizenziert sind und zusätzlich Lizenzkapazität aus dem 9.x-Abonnement verbrauchen (KB 441187). Ersatz-Hosts können die zu lizenzierende Kernzahl verändern (Leitfaden zur Kernzählung); Extended Support behandelt unser Leitfaden zum VMware-Support nach Broadcom. Welche Hosts wechseln, warten oder ausscheiden, gehört in den Maßnahmenplan mit Terminen, den unsere VMware-Optimierung vor Verlängerung und Supportende erstellt.

Was wir tun

Eurokommerz hält den Vertrag und liefert die Hardware zur Lösung, mit EU-Rechnungsstellung, Lieferung und Garantie nach europäischem Recht; die technische Umsetzung übernimmt unser Engineering-Partner Vixen.UNO. Im Rahmen der VMware-Optimierung erstellt das Vixen.UNO-Team eine vollständige Inventur Ihrer VMware-Umgebung und einen Maßnahmenplan vor Verlängerung und Supportende, mit Terminen. Der erste Schritt ist ein kostenloses Erstgespräch; das kostenpflichtige technische Assessment, dessen Preis vor Arbeitsbeginn feststeht, liefert einen Bericht, ein TCO- und ROI-Modell und diesen Plan. Upgrades von vSphere, vSAN, NSX und VCF folgen in vereinbarten Wartungsfenstern mit einem Rollback-Plan für jede Etappe, danach Support unter einem vereinbarten SLA. Unser Infrastruktur-Audit, ein eigenständiges Produkt zum Festpreis, arbeitet mit den Exporten, die Sie bereitstellen, ohne Zugriff auf Ihre Produktivsysteme.

FAQ