vSphere 8 auf VCF 9 Upgrade: Converge, Import oder Neubereitstellung und die Upgrade-Schritte der Reihe nach

vSphere 8 auf VCF 9 Upgrade: die Wege, die Broadcom dokumentiert

Eine bestehende vSphere-8-Umgebung erreicht VMware Cloud Foundation (VCF) 9.1 auf einem von drei Wegen aus Broadcoms Dokumentation zu 9.1: Sie konvergieren das bestehende vCenter und seine ESX-Hosts mit dem VCF Installer in die Management-Domain einer neuen VCF-Instanz, importieren ein vCenter als Workload-Domain in eine bestehende VCF-Instanz oder stellen eine neue VCF-9.1-Umgebung bereit und migrieren die Workloads. Für Umgebungen mit nur vSphere, vSAN und Aria Operations dokumentiert Broadcom außerdem ein Upgrade Komponente für Komponente, das vCenter und ESX 8 Update 3 auf 9.1 bringt und sich später zu vSphere Foundation (VVF) oder VCF erweitern lässt. Die Wahl hängt von NSX, SDDC Manager und Aria ab, von den genauen Builds und von den Lizenzen.

Broadcoms Übersicht „Paths to Building 9.1.x Environments“ (8. Oktober 2026) ordnet sie in Neubereitstellung, Converge und Upgrade, mit dem Import für Workload-Domains; Umgebungen auf VCF 5.2.x mit SDDC Manager aktualisieren stattdessen ihre VCF-Instanz. Broadcom nennt Oktober 2027 als Ende des Supports für vSphere 8, wie unser Leitfaden zum Ende des allgemeinen Supports von vSphere 8 darlegt.

Converge, Import oder Neubereitstellung: welcher Weg passt

Broadcom TechDocs VCF 9.1: Paths to Building 9.1.x Environments, Upgrading vSphere 8 to 9.1.x und Supported Components and Scenarios to Converge to VCF (alle 8. Oktober 2026); FAQ zu VCF 9.1, Q59 bis Q68 (3. September 2026); KB 450972.

Converge und Import arbeiten mit ganzen vCenter-Instanzen: Laut der FAQ zu VCF 9.1 „wird Infrastruktur auf vCenter-Ebene hinzugefügt“, und beide Vorgänge „erfordern keine Ausfallzeit und keine Migration von Anwendungen oder Daten“. Für Cluster ohne NSX heißt es: „NSX wird im Rahmen des Convert- bzw. Import-Vorgangs automatisch bereitgestellt.“ Die FAQ nennt in Q59 8.0 Update 1 als Mindestversion für den Import, in Q63 aber 8.0 Update 3, wie auch KB 450972; planen Sie mit Update 3.

Bei mehreren vCenter-Instanzen konvergiert der VCF Installer eine davon in eine Management-Domain, und VCF Operations importiert die übrigen als Workload-Domains. Wo bereits NSX läuft, lässt Broadcoms KB 440630 keine Option Komponente für Komponente zu und schickt die Umgebung durch die Workflows des VCF Installers. Broadcom dokumentiert außerdem ein Converge zu vSphere Foundation 9.1; was das für einen späteren Wechsel zu VCF bedeutet, steht in unserem Vergleich von VVF und VCF.

Eine Neubereitstellung auf neuen Servern eignet sich für Umgebungen, deren Hosts ESX 9 nicht ausführen können, oder für eine vCenter-Konfiguration, die Converge nicht unterstützt. Die Workloads wechseln per Cross vCenter vMotion oder, innerhalb von VCF, mit HCX.

Builds von vCenter und ESX: die Back-in-Time-Regel

Broadcom unterstützt kein Upgrade von einer Quelle, die „Code-Fixes, Sicherheitspatches oder Treiber-Updates enthält, die im Ziel-Release noch nicht vorhanden sind“ (KB 450972). Für VCF 9.1.0 unterstützt die KB Upgrade, Converge und Import von vSphere 8.0 U3 bis 8.0 U3i, von 8.0 U3j und U3k dagegen nur den Import.

KB 448135 ergänzt, dass VCF 9.1.1.0 „mit einer aktualisierten Bill of Materials (BOM) veröffentlicht wurde“, was die Sperre für vSphere 8.0 U3j und neuer sowie für NSX 4.2.4 und neuer aufhebt. Die Release Notes zu VCF 9.1.1 (GA am 3. September 2026) erlauben es, bestehende Infrastruktur direkt auf 9.1.1 zu konvergieren oder direkt auf 9.1.1 neu bereitzustellen. Für eine Umgebung, die auf U3j oder U3k gepatcht ist, lautet das Ziel daher 9.1.1, nicht 9.1.0. KB 448135 verlangt außerdem, jeden Pfad in der VMware Interoperability Matrix zu bestätigen, und zwar ohne Haken bei „Hide Patch Releases“.

Der Import fällt nicht unter die Regel, denn KB 450972 bezeichnet ihn als „einen Onboarding-Vorgang und keinen Upgrade-Vorgang“. Er stellt das vCenter unter „eine bestehende VCF 9.1 Fleet“, während seine Hosts auf ihren Patches von 8.0 Update 3 bleiben; eine Umgebung mit U3j oder U3k ohne VCF-Instanz braucht daher zuerst eine Management-Domain auf anderen Hosts oder den Weg über 9.1.1.

Lizenzen vor dem ersten Wartungsfenster

Die FAQ zu VCF 9.1 vom 3. September 2026 sagt, dass Kunden mit Dauerlizenzen „vor dem Upgrade auf Abonnementlizenzen umstellen müssen“. Broadcoms KB 437250 ergänzt: „Der Lizenzschlüssel kann nicht von Version 8.x auf 9.x aktualisiert werden“; die Broadcom Site ID braucht ein Abonnement mit Berechtigung für VCF 9 oder VVF 9. In 9.1 sind „VCF Operations und die Komponenten des Lizenzservers erforderlich, um alle 9.1.x-Umgebungen zu lizenzieren“, daher kommen beide vor vCenter.

Der Lizenzserver wird aus einer OVA bereitgestellt, mit einem Registrierungsschlüssel aus VCF Operations, in eine damit verbundene vCenter-Instanz, nicht auf einen eigenständigen ESX-Host. Er braucht einen FQDN mit A- und PTR-Records, den jedes vCenter, das ihn nutzt, auflösen kann, und er unterstützt kein IPv6.

Ein aktualisiertes vCenter 9.1 läuft bis zu 90 Tage im Evaluierungsmodus, bis es eine primäre Lizenz erhält. Broadcoms Lizenzierungshandbuch zu 9.1 akzeptiert ESXi-8.x-Hosts mit 8.x-Schlüsseln unter einem vCenter 9.1, wobei zusätzlich Kapazität aus dem 9.x-Abonnement verbraucht wird.

Voraussetzungen für eine Umgebung mit 10 bis 60 Hosts

Beginnen Sie mit einer Inventur je vCenter-Instanz: Hosts mit ESX-Builds und CPU-Modellen, die Lifecycle-Methode jedes Clusters, der Switch-Typ, NSX- und Aria-Komponenten, Enhanced Linked Mode und vCenter High Availability. Drei Ergebnisse daraus entscheiden über den Weg. Cluster, die noch Baselines nutzen, wechseln zuerst auf vLCM-Images, wie in unserem Leitfaden zur Umstellung von vLCM-Baselines auf Images beschrieben. Hosts mit eingestellten CPUs oder End-of-Life-Geräten können ESX 9 nicht ausführen; die Prüfungen stehen in unserem Leitfaden zu den Hardware-Anforderungen für ESX 9.

Das dritte ist Broadcoms Liste der Konfigurationen, die für ein Converge zu VCF 9.1 nicht unterstützt werden: vCenter-Instanzen mit Enhanced Linked Mode oder ohne Distributed Switch, eine vCenter-VM auf einem Cluster, den ein anderes vCenter verwaltet, virtuelle Switches von Cisco, dynamisch zugewiesene VMkernel-IP-Adressen, Cluster mit Baselines, Cluster mit manuellem oder teilautomatisiertem DRS, Cluster mit vCenter High Availability und der teilweise Import von Clustern. Eine konvergierte Management-Domain braucht im einfachen Modell mindestens 3 ESX-Hosts mit vSAN oder 2 mit externem Storage und im Hochverfügbarkeitsmodell 4 Hosts.

Für das vCenter-Upgrade verlangen Broadcoms Voraussetzungen für 9.1 (5. Oktober 2026) synchronisierte Uhren, DRS auf manuell oder teilautomatisiert (ein späteres Converge braucht vollautomatisiertes DRS), offene Ports 22 und 443 sowie Forward- und Reverse-DNS-Einträge für eine statische temporäre Adresse. Sie verlangen ein imagebasiertes Backup (Snapshot) der Appliance „als Vorsichtsmaßnahme“. Erstellen Sie unmittelbar vor dem Wartungsfenster zusätzlich ein dateibasiertes Backup, wie in unserem Leitfaden zur dateibasierten Sicherung und Wiederherstellung von vCenter beschrieben.

Dasselbe Handbuch zu 9.1 legt fest, wo die neue Appliance läuft: „Sie können die neue Appliance auf einem ESX-Host 9.0 oder neuer oder im Inventar einer vCenter-Instanz 9.0 oder neuer bereitstellen.“ Seine Seite zu den Systemanforderungen nennt an einer Stelle ESX 9.1. Wo alle Hosts noch ESXi 8 ausführen, planen Sie vor dem vCenter-Wartungsfenster einen ESX-9.1-Host für die Appliance ein, etwa einen Reserveserver oder einen neuen Server, und lassen Sie sich die Platzierung vom Broadcom-Support bestätigen.

Upgrade-Schritte von vSphere 8 auf 9.1 der Reihe nach

Broadcoms Szenario für 9.1 für vSphere-8-Umgebungen sieht sechs Schritte vor. KB 440630 sagt „Eine verbindliche Upgrade-Reihenfolge der Komponenten muss eingehalten werden“, ohne jedes Produkt aufzuführen; Backup-Produkt, Replikation und vSAN-Witness erhalten ihren Platz daher aus Broadcoms Reihenfolge für VCF 9.0, KB 390634.

1. Aktualisieren Sie Aria Operations 8.18 oder neuer nach einem Snapshot jedes Knotens auf VCF Operations 9.1, oder stellen Sie VCF Operations 9.1 aus seiner OVA auf dem vCenter bereit, das die Kernkomponenten hostet.
2. Stellen Sie den Lizenzserver bereit, prüfen Sie, dass VCF Operations ihn als „Connected“ anzeigt, und kontrollieren Sie, dass das 9.x-Abonnement erscheint.
3. Aktualisieren Sie das VADP-basierte Backup-Produkt, vSphere Replication und Site Recovery Manager auf Releases, die mit dem Ziel-vCenter unterstützt werden.
4. Aktualisieren Sie vCenter mit der zweistufigen GUI des Installers oder seiner CLI auf 9.1, mit der neuen Appliance auf einem ESX-9.x-Host, und weisen Sie dann in VCF Operations die primäre Lizenz zu.
5. Aktualisieren Sie die vSAN-Witness-Hosts von Stretched Clustern oder Zwei-Knoten-Clustern.
6. Aktualisieren Sie die ESX-Hosts Cluster für Cluster: ein 9.1-Basis-Image mit dem Add-on des Serverherstellers, eine Compliance-Prüfung, die Vorabprüfung vor der Standardisierung (Remediation), ein Host, dann die übrigen.
7. Aktualisieren Sie VMware Tools und, wo ein Workload es braucht, die virtuelle Hardware.
8. Aktualisieren Sie das On-Disk-Format jedes vSAN-Clusters, dann den vSAN File Service, wo er läuft.

KB 390634 ergänzt: „Patches können in beliebiger Reihenfolge eingespielt werden. Die Upgrade-Reihenfolge spielt nur bei Major- und Minor-Releases eine Rolle.“ Das Upgrade des On-Disk-Formats von vSAN setzt abgeschlossene Upgrades von ESX und vCenter, fehlerfreie Datenträger, keinen Host im Wartungsmodus und keinen laufenden Rebuild voraus, und es „kann vorübergehend Resynchronisierungsverkehr verursachen und zusätzlichen Speicherplatz belegen“.

Unsere VMware-Optimierung führt diese Schritte in vereinbarten Wartungsfenstern mit einem Rollback-Plan aus. Schicken Sie uns Ihre Builds von vCenter und ESX über das Formular unten, mit den Clustern, die jedes vCenter verwaltet.

Rechenbeispiel: 40 Hosts in vier Clustern

Nehmen wir ein vCenter 8.0 U3, das 40 Hosts verwaltet: einen Management-Cluster mit 4 Hosts und einen Produktionscluster mit 16 Hosts auf vSAN, einen Produktionscluster mit 12 Hosts und einen Datenbankcluster mit 8 Hosts auf Fibre-Channel-VMFS, mit Aria Operations 8.18 und ohne NSX. Es gilt das Szenario des Komponenten-Upgrades. Broadcoms Lifecycle-Handbuch zu vSphere 9.0 hält fest, dass „Sie ESX nicht downgraden können“; daher endet jedes Wartungsfenster an einem Punkt, der entweder wiederherstellbar ist oder geprüft wird, bevor das nächste beginnt.

Unser Beispiel und unsere Planungsreihenfolge; Schritte aus Broadcom TechDocs VCF 9.1 (Upgrade-Szenario, Upgrade von VCF Operations und On-Disk-Format von vSAN, 8. Oktober 2026), den Voraussetzungen für das Upgrade auf vCenter 9.1 (5. Oktober 2026), dem Lifecycle-Handbuch zu vSphere 9.0 und KB 390634.

Ein Wartungsfenster kann einen Teil eines Clusters umfassen: Broadcoms KB 424129 sagt, dass vCenter 9.0 ESX-8.0-Hosts im selben Cluster wie ESX-9.0-Hosts verwalten kann. Ein Cluster, der für den Ausfall eines Hosts dimensioniert ist, verliert diese Reserve, solange ein Host im Wartungsmodus ist; planen Sie den Datenbankcluster daher für die Zeit seiner geringsten Last ein.

Converge zu VCF nach dem Upgrade oder direkt von 8.0 U3

Um VCF zu betreiben, kann die Umgebung im Beispiel von 8.0 U3 aus mit dem VCF Installer konvergieren oder zuerst das Komponenten-Upgrade abschließen, das Broadcom als stabile Umgebung beschreibt, die sich später zu VVF oder VCF 9.1.x erweitern lässt. Bei einem einzigen vCenter bringt Converge alle vier Cluster in die Management-Domain, denn „alle von der Instanz verwalteten Cluster werden gemeinsam in die Management-Domain importiert“.

Broadcoms Übersicht zu Converge (8. Oktober 2026) beschreibt Voraussetzungen, manuelle Upgrades bestehender Komponenten und dann Bereitstellungen durch den VCF Installer, der „Ihre vCenter-Instanz und Ihre ESX-Hosts verwendet, um die Management-Domain für die neue Instanz zu erstellen“, und „alle erforderlichen Komponenten bereitstellt, die in Ihrer bestehenden Umgebung fehlen“. Die Szenarioseite, die zu dem passt, was heute läuft, legt fest, welche Komponenten Sie zuerst von Hand aktualisieren.

NSX 4.2.1 oder neuer, registriert bei einem vCenter ohne Enhanced Linked Mode, wird in seiner aktuellen Version konvergiert und danach auf 9.1 aktualisiert. VMware Aria Suite Lifecycle „ist nicht Teil von VCF 9.1.x“.

Unser Umgebungs- und Lizenz-Audit erstellt eine vollständige Inventur Ihrer VMware-Umgebung. Beschreiben Sie Ihre vCenter-Instanzen sowie NSX- und Aria-Komponenten im Formular unten, mit den Builds, die jede davon ausführt.

Was wir tun

Eurokommerz hält den Vertrag; die technische Umsetzung übernimmt unser Engineering-Partner Vixen.UNO. Im Rahmen der VMware-Optimierung endet das Audit Ihrer Umgebung und Ihrer Lizenzen in einem Maßnahmenplan vor Renewal und End of Support, mit Terminen. Das Upgrade auf 9.x, Teil der Modernisierung von vSphere, vSAN, NSX und VCF, läuft in vereinbarten Wartungsfenstern, Schritt für Schritt, mit einem Rollback-Plan für jede Etappe. Das erste Gespräch ist kostenlos, der Preis der technischen Bewertung wird vor Beginn der Arbeiten festgelegt, und der Support läuft unter einem vereinbarten SLA weiter.

FAQ