VCF 9.1 Neuerungen: Release-Datum, Builds, Änderungen je Komponente, Lizenzierung und Upgrade-Pfade

VCF 9.1: Release-Datum, Build-Nummern und die wichtigsten Änderungen

VMware Cloud Foundation (VCF) 9.1 ist laut Broadcoms Release Notes und KB 314608 am 12. Mai 2026 erschienen. Die Bill of Materials führt ESX 9.1.0.0 als Build 25370933, vCenter 9.1.0.0 als Build 25370922, NSX 9.1.0.0 als Build 25318225 und den VCF Installer sowie SDDC Manager als Build 25371088. Das Wartungsrelease 9.1.1 folgte am 3. September 2026 mit ESX-Build 25714478 und vCenter-Build 25712839, und am 12. Oktober 2026 hat Broadcom Patches für Komponenten von 9.1.1 veröffentlicht. Die Release Notes, zuletzt aktualisiert am 15. Oktober 2026, sagen: „Verwenden Sie bei Bereitstellung, Upgrade und Patching die neuesten verfügbaren Binärdateien der Komponenten.“

Für eine Umgebung mit 10 bis 60 Hosts wiegen fünf Änderungen am schwersten. Lizenzen wandern auf einen Lizenzserver, der über VCF Operations verwaltet wird. Live Patching funktioniert nun auf ESX-Hosts mit TPM, laut Broadcom für bis zu 80 % der Patches, und vCenter erhält Quick Patches mit kurzer Ausfallzeit. Memory Tiering über NVMe lässt sich ohne Host-Neustart konfigurieren, und vSAN ESA ergänzt globale Deduplizierung mit RAID-6 als Standard. Das Lifecycle-Management wandert in VCF Operations, und USB- und SD-Boot, unverschlüsseltes Syslog an vCenter auf Port 514 sowie vCLS sind abgekündigt oder abgeschaltet.

Broadcom TechDocs, Release Notes zu VCF 9.1.0: What’s New und die Seiten der Komponenten (aktualisiert am 12. und 15. Oktober 2026) sowie Product Support Notes (15. Oktober 2026).

vSphere 9.1 und ESX 9.1: Hosts, Speicher und vMotion

Broadcoms What’s-New-Seite führt Live Patching für ESX auf Hosts mit TPM auf, „das bis zu 80 % der Patches abdeckt“. Der Patch wird auf den laufenden Kernel-Speicher angewendet, während die VMs weiterlaufen. Broadcoms VCF-Blogbeitrag vom 12. Mai 2026 ergänzt, Live Patch sei „standardmäßig auf allen Clustern aktiviert“, und ein Patch, der sich nicht live anwenden lässt, falle auf Wartungsmodus und Neustart zurück.

Zero Touch Provisioning installiert ESX auf Bare-Metal-Servern über einen abgesicherten Netzwerk-Boot mit UEFI und HTTPS. Broadcom nennt es „einen zukunftsgerichteten Ersatz für das ältere Auto Deploy, das in VCF 9.0 abgekündigt ist“.

Memory Tiering hält aktive Seiten im DRAM und verschiebt kalte Seiten auf lokale NVMe. In ESX 9.1 erfordern das Aktivieren und die Auswahl des Geräts keinen Host-Neustart mehr, Einschränkungen für die VM-Typen, die auf einem Host mit Tiering starten können, entfallen, und ein zweites NVMe-Gerät kann die Speicherstufe als RAID 1 spiegeln. Voraussetzungen, Verhältnisse und Dimensionierung stehen in unserem Leitfaden zu vSphere Memory Tiering mit NVMe.

User-Level Monitor wird „der Standardmonitor für alle virtuellen Maschinen“, und AMD SEV-SNP und Intel TDX für Confidential VMs erreichen General Availability. Für DRS und vMotion nennt Broadcom einen unterbrechungsfreien Wartungsmodus, der laut demselben Blogbeitrag eine VM nur dann evakuiert, wenn die Zielhosts ihren aktuellen Rechenbedarf decken können, und eine dynamische Steuerung der Parallelität, die über das statische clusterweite Limit von acht gleichzeitigen Migrationen hinausgeht.

vCenter 9.1 und vSphere Lifecycle Manager

vCenter-Quick-Patches aktualisieren vCenter laut TechDocs-Seite „mit null bis 5 Minuten Ausfallzeit“. Broadcoms Blog spricht von unter einer Minute; planen Sie die Wartungsfenster daher nach dem Wert aus TechDocs. Die Überwachung der Dateiintegrität ist standardmäßig aktiv und läuft alle vier Stunden, und ein Log-Agent, der an VCF Operations sendet, ist vorinstalliert.

vSphere Lifecycle Manager ergänzt globale Einstellungen für die Remediation, die festlegen, wie sich Hosts und VMs vor und während der Remediation eines Clusters verhalten, und prüft die Integrität angepasster ESX-Images. Die Support Notes sperren den unverschlüsselten Syslog-Port 514 (UDP und TCP) auf vCenter; jedes Gerät und jedes Skript, das noch Syslog auf Port 514 an vCenter sendet, wechselt daher vor dem Upgrade auf den TLS-verschlüsselten Port 1514. vSphere Cluster Services (vCLS) „ist standardmäßig deaktiviert, und Sie können die Funktion nicht wieder aktivieren“, und seine Funktionen sind aus den Oberflächen von SDDC Manager und VCF Installer entfernt.

vSAN 9.1 und NSX 9.1

In vSAN ESA „verwenden vSAN-Cluster RAID-6 als Standard-RAID-Level“ unter Auto-RAID. Globale Deduplizierung kommt als clusterweite Einstellung mit nachgelagerter Verarbeitung (Post-Processing) und mit Unterstützung für Verschlüsselung. Ein ganzer Standort eines Stretched Clusters kann nun in den Wartungsmodus gehen. vSAN Replication akzeptiert VMs auf beliebigem Storage als Quelle, mit vSAN ESA als Ziel.

NSX 9.1 führt die Virtual Network Appliance und eine Reihe von VPC-Funktionen ein, darunter Load Balancing auf dieser Appliance und IPsec-VPN auf einem zentralisierten Transit-Gateway. Die Management-Domain kann ihre NSX Manager mit Workload-Domains teilen. Edge-Cluster werden nun am Ende der Upgrade-Reihenfolge einer Domain aktualisiert, was Broadcom als zusammengelegte Wartungsfenster für NSX und vSphere beschreibt. NSX 9.1 unterstützt kein IPFIX auf Uplink-Portgruppen von Distributed Switches, das vCenter 9.1 abkündigt.

VCF Operations, Fleet Lifecycle und Wiederherstellung

In VCF 9.1 „gibt es die eigenständige VCF Operations Fleet Management Appliance nicht mehr“, und das Lifecycle-Management läuft als Fleet Lifecycle innerhalb von VCF Operations. Ein Cluster-Upgrade kann nun ausgewählte Hosts statt des ganzen Clusters erfassen, und eigenständige Hosts sowie Cluster mit nur einem Host fallen unter das Lifecycle-Management.

Security Posture Management ersetzt die abgekündigte Compliance-Funktion. Die Support Notes halten außerdem fest, dass „die direkte vCenter-Authentifizierung für VCF Operations entfernt wurde“, und mit ihr entfällt die API-Authentifizierung mit vCenter-Anmeldedaten; Teams und Skripte, die sich mit vCenter-Konten bei VCF Operations anmelden, brauchen daher vor dem Upgrade eine andere Identitätsquelle. Für die Wiederherstellung nennt die What’s-New-Seite „integrierte Cyber Recovery in isolierte VCF-Clean-Rooms on-premises“, und die Bill of Materials führt Protection and Recovery 9.1.0.0 unter den VCF-Diensten mit „Add-on“ in der Spalte für die Aufnahme in die VCF-SKU; prüfen Sie daher das Abonnement, bevor Sie damit planen.

Lizenzierung von VCF 9.1: Lizenzserver und Connected Mode

Die Seite zu VCF Operations in den Release Notes sagt: „Ihre Lizenzen werden jetzt in einem Lizenzserver gespeichert statt in VCF Operations“. Broadcoms Übersicht zum Lizenzserver, aktualisiert am 12. Oktober 2026, sagt, ein Lizenzserver „wird bei neuen Bereitstellungen von VCF oder vSphere Foundation und bei Upgrades auf Version 9.1 und höher bereitgestellt“, und die meisten Instanzen von VCF Operations brauchen nur einen. Ein Lizenzserver kann nicht von mehreren Fleets gemeinsam genutzt werden, und sein Netzwerkpfad braucht eine Latenz von höchstens 300 ms. Bei einem Ausfall laufen Workloads und Verwaltungsvorgänge weiter, bis die nächste Nutzungsmeldung fällig ist, aber Lizenzen lassen sich nicht zuweisen.

Bevor Assets lizenziert werden können, werden VCF Operations und ein Lizenzserver bei der VCF Business Services console registriert. Im Connected Mode, den Broadcom empfiehlt, lädt VCF Operations alle 24 Stunden eine neue Lizenzdatei herunter. Im Disconnected Mode erzeugt ein Administrator eine Nutzungsdatei und lädt sie hoch. Broadcoms Lizenzierungsübersicht verlangt Nutzungsmeldungen „mindestens einmal alle 180 Tage, um Ihre Lizenzen aufrechtzuerhalten“. Eine Lizenz, deren Nutzung nicht gemeldet und die nicht aktualisiert wird, läuft ab, und 90 Tage später trennen sich die ESX-Hosts von vCenter und Workloads lassen sich nicht mehr starten, während laufende Workloads nicht gestoppt werden. Lizenzen lassen sich nun einzelnen Assets als Override der vCenter-Lizenz zuweisen, und die Nutzung von Hosts mit ESX 8.x und 9.x wird gemeinsam gemeldet. Was VVF und VCF jeweils enthalten und wie Override-Lizenzen beide mischen, steht in unserem Vergleich von VVF und VCF 9.1.

Unsere Lizenzoptimierung stimmt Editionen und Abonnements innerhalb der aktuellen Broadcom-Lizenzlogik auf Ihre realen Workloads ab. Schreiben Sie uns Ihre vCenter-Instanzen und das Enddatum Ihres Abonnements, und nennen Sie uns, ob VCF Operations heute im Connected Mode läuft.

Upgrade-Pfade auf VCF 9.1 von 9.0, 5.2 und vSphere 8

VCF 5.2.x und 9.0.x werden per In-Place-Upgrade aktualisiert, beginnend mit der VCF-Instanz, die VCF Operations hostet, und mit VCF Operations vor SDDC Manager. Von 5.2.x aus kann das Upgrade sequenziell oder als Skip-Level-Upgrade erfolgen, während eine Umgebung mit einer früheren VCF-Version zuerst ihre Management-Domain und alle Workload-Domains auf 5.2.x bringt. Workload-Domains können später als Day-N-Vorgang folgen. Umgebungen mit vSphere 8 werden konvergiert, importiert oder Komponente für Komponente aktualisiert, wie unsere Schritt-für-Schritt-Anleitung zum Upgrade von vSphere 8 auf VCF 9 erklärt.

Auch die Release-Daten begrenzen das Ziel. Broadcom unterstützt ein Upgrade nur auf „eine Zielversion, die nach dem Release-Datum Ihrer aktuellen Version veröffentlicht wurde“, und schließt in seinem eigenen Beispiel den Weg von VCF 5.2.4, veröffentlicht am 27. Mai 2026, auf 9.1.0 aus. Für vSphere 8 unterstützt KB 450972 Upgrade, Converge und Import auf 9.1.0 von 8.0 U3 bis U3i, von U3j und U3k dagegen nur den Import. KB 448135 sagt, VCF 9.1.1.0 sei „mit einer aktualisierten Bill of Materials (BOM) veröffentlicht worden“, was die Sperre für vCenter und ESXi 8.0 U3j und neuer sowie für NSX 4.2.4 und neuer aufhebt. Die Regel zum Release-Datum gilt weiterhin für jeden Patch von 8.0, der nach 9.1.1 vom 3. September 2026 erscheint. Die Release Notes zu vCenter 8.0 U3k (29. Juli 2026, aktualisiert am 16. September 2026) sagen weiterhin, der Vorwärtspfad auf 9.1.x „wird in einem künftigen 9.1.x-Release verfügbar sein“; bestätigen Sie Quellen mit U3k daher in der Interoperability Matrix.

Broadcom TechDocs VCF 9.1: Upgrading VMware Cloud Foundation und Release Notes zu VCF 9.1.1 (beide aktualisiert am 15. Oktober 2026); KB 450972 und KB 448135 (ohne Datumsangabe, gelesen am 16. Oktober 2026).

Prüfungen vor dem Upgrade auf VCF 9.1

Die Reihenfolge unten stammt von uns; jeder Schritt stützt sich auf die oben genannten Dokumente von Broadcom.

1. Erfassen Sie jedes vCenter, jeden ESX-Host, jeden NSX Manager und jede Instanz von VCF Operations mit ihrem Build, und ordnen Sie jedem Build mit KB 314608 und der Bill of Materials sein Release-Datum zu.
2. Prüfen Sie jedes Paar aus Quelle und Ziel in der Broadcom Interoperability Matrix ohne Haken bei „Hide Patch Releases“, wie KB 448135 es verlangt.
3. Prüfen Sie die Hosts gegen die Hardware-Anforderungen von ESX 9.1; USB- und SD-Bootgeräte sowie Systemspeicher unter 32 GB sind zur Entfernung im nächsten Major Release abgekündigt, wie unser Leitfaden zu den Hardware-Anforderungen von ESX 9 darlegt.
4. Ermitteln Sie, was Syslog auf Port 514 an vCenter sendet, wer sich mit vCenter-Konten bei VCF Operations anmeldet und welche Skripte APIs aufrufen, die in 9.1 entfernt wurden, etwa die vStats APIs und die NSX Logical MP API für Port Mirroring.
5. Planen Sie den Lizenzserver, seine Registrierung in der VCF Business Services console und den Connected oder Disconnected Mode vor dem ersten Wartungsfenster.
6. Wählen Sie 9.1.1 oder einen späteren Patch, wo die Quelle es zulässt, da Broadcom die neuesten verfügbaren Binärdateien verlangt, und halten Sie das Ende des General Support für das Release fest, auf dem Sie landen, mit den Daten aus unserem Leitfaden zum Supportende von vSphere 9.

Unsere VMware-Optimierung führt Versions-Updates von vSphere, vSAN, NSX und VCF in vereinbarten Wartungsfenstern mit Rollback-Plan durch. Schicken Sie uns die Builds jedes vCenter und jedes Clusters über das Formular unten, mit den offenen Punkten aus dieser Liste.

Was wir tun

Im Rahmen der VMware-Optimierung hält Eurokommerz den Vertrag, und die technische Umsetzung übernimmt unser Engineering-Partner Vixen.UNO. Das Umgebungs- und Lizenz-Audit erstellt eine vollständige Inventur Ihrer VMware-Umgebung mit Versionen, Subscriptions und tatsächlicher Ressourcennutzung, und das technische Assessment endet in einem Maßnahmenplan vor Renewal und End of Support, mit Terminen. Die Modernisierung von vSphere, vSAN, NSX und VCF auf 9.1 läuft dann in vereinbarten Wartungsfenstern, Schritt für Schritt, mit einem Rollback-Plan für jede Etappe, danach folgt Support unter einem vereinbarten SLA. Das erste Gespräch ist kostenlos, und der Preis des technischen Assessments steht vor Beginn fest.

FAQ