vLCM-Baselines zu Images: wie Sie vSphere-Cluster vor 9.x umstellen und welche Fehler die Umstellung stoppen

vLCM-Baselines vor vSphere 9 auf Images umstellen

Um einen Cluster in vSphere Lifecycle Manager (vLCM) von Baselines auf ein Image umzustellen, öffnen Sie im vSphere Client seine Registerkarte Updates und klicken unter vCenter 8.0 auf Image oder unter vCenter 9.0 auf Image Setup. Dann übernehmen Sie das Image von einem Host, aus einer JSON-Datei oder aus einer manuellen Definition, validieren und speichern es und schließen die Einrichtung des Images ab. Die Hosts ändern sich erst mit der Remediation, und der Cluster kann nicht zu Baselines zurückkehren. Laut Broadcoms Support Notes zu vSphere in VCF 9.0 (29. September 2026) wird die Verwaltung von Clustern mit Baselines und Baseline-Gruppen „in vCenter 9.0 nicht mehr unterstützt“. Die Umstellung kann unter vCenter 8.0 laufen oder nach dem Upgrade auf vCenter 9.0, bevor die Hosts auf ESX 9 wechseln, mit einer dokumentierten Ausnahme für gemischte Hardware.

Broadcom hat Baselines mit vSphere 8.0 als veraltet eingestuft (KB 322186), und KB 379388 führt auf, was vCenter 9.0 noch erlaubt. Ein bestehender Baseline-Cluster mit 8.x-Hosts lässt sich innerhalb von 8.x patchen, doch „ISO-basierte Upgrades werden für jede ESX-Hostversion blockiert“, 9.x-Hosts lassen sich nicht mit Baselines patchen, und neue Cluster und eigenständige Hosts erhalten standardmäßig Images. Broadcoms Dokumentation zu VCF 9.0 (29. September 2026) ergänzt, dass Baselines „mit VMware Cloud Foundation 9.0 oder neuer nicht unterstützt werden“. Die Termine und die Upgrade-Reihenfolge stehen in unserem Leitfaden zum Ende des allgemeinen Supports von vSphere 8.

Was ein vLCM-Image enthält

Ein Image legt fest, welche Software jeder Host in einem Cluster oder ein eigenständiger Host ausführen soll, und „das Basis-Image ist das einzige obligatorische Element“. Das Basis-Image ist das ESX-Image, das mit jedem ESX-Release ausgeliefert wird. Serverhersteller bündeln ihre Komponenten, etwa Treiber und Patches, als Hersteller-Add-on. Ein Firmware- und Treiber-Add-on braucht den Hardware Support Manager des Serverherstellers, ein vCenter-Plug-in, dessen „Bereitstellungsmethode, Nutzungsrecht und Lizenzierung“ der Serverhersteller bestimmt. Unabhängige Komponenten fügen Software von Drittanbietern hinzu, etwa Treiber; auf GPU-Hosts gehört auch der NVIDIA vGPU Manager, ein Hosttreiber, in das Image, wie unser Leitfaden zu GPUs in vSphere beschreibt.

In vSphere 9.0 dient ein zusammengesetztes Image (Composite Image) einem Cluster, „der Hosts verschiedener Hersteller oder desselben Herstellers, aber unterschiedlicher Generationen, Familien oder Modelle enthält“. Seine Images teilen sich Basis-Image und Lösungen, während sich Hersteller- und Firmware-Add-ons unterscheiden können.

vLCM-Image vs Baseline unter vCenter 9

Die Tabelle vergleicht beide Methoden unter vCenter 9.0.

Broadcom KB 379388 und KB 419331, Stand Oktober 2026; Handbuch zu vSphere Lifecycle Manager 9.0, Vergleich von Images und Baselines sowie Hardwarekompatibilitätsprüfungen auf Host-Ebene (24. August 2026).

Eignungsprüfungen vor der Umstellung eines Clusters

Die Einrichtung des Images beginnt mit einer Eignungsprüfung. Drei Bedingungen verhindern den Wechsel: ein Host, der nicht stateful ist, also nicht von einem Datenträger bootet; ein Host mit einer Version vor ESXi 7.0 unter vCenter 8.0 oder vor 8.0 unter vCenter 9.0; und VIBs einer nicht integrierten Lösung, die zuerst deaktiviert werden muss. Warnungen betreffen Software außerhalb des Images. Ein eigenständiges VIB, dessen Komponente im Depot liegt, muss dem Image hinzugefügt werden; ein unbekanntes VIB ohne Komponente im Depot muss importiert werden, sonst löscht die Remediation es. Broadcom bittet Sie außerdem, bei jedem Drittanbieter zu klären, „ob die jeweilige Lösung mit vSphere Lifecycle Manager funktioniert“.

Für ein einzelnes Image müssen alle Hosts vom selben Hardwarehersteller stammen. Unter vCenter 8.0 setzt die Übernahme des Images von einem Host außerdem ESXi 7.0 Update 2 und vCenter 8.0 Update 3 voraus. Cluster mit NSX brauchen einen verbundenen NSX-Compute-Manager und ein Transport Node Profile (KB 445081, KB 447693). Erstellen Sie unmittelbar vor dem Wechsel ein dateibasiertes Backup von vCenter, nachdem Sie die Grenzen des Rollbacks weiter unten gelesen haben; Zeitpläne und Wiederherstellung behandelt unser Leitfaden zur dateibasierten Sicherung und Wiederherstellung von vCenter.

Depot-Inhalte: Download-Token, UMDS und Offline-Bundles

Ein Image kann nur verwenden, was im vLCM-Depot liegt. Laut KB 379388 wird vLCM „keine Updates mehr aus den öffentlichen, aus dem Internet erreichbaren Repositorys von VMware by Broadcom herunterladen können“. Die neue Adresse ist laut KB 390121 eine URL unter dl.broadcom.com mit einem kundenspezifischen Download-Token, das „nur Benutzer mit der Rolle Product Administrator“ in Broadcoms Supportportal erzeugen können (KB 390098).

Ohne Internetzugang kommen die Inhalte vom Update Manager Download Service (UMDS) oder aus Offline-Bundles. UMDS lässt sich „nur auf Linux-basierten Betriebssystemen“ installieren, lädt Komponenten ebenso wie Legacy-Bulletins herunter und übergibt sie auf Wechselmedien oder über einen Webserver. Auch UMDS braucht das Download-Token; ohne Token scheitern die Download-Jobs mit „HTTP Error Code: 403“ (KB 390123). Seine Version muss zu vLCM passen („vSphere Lifecycle Manager 9.0 ist mit UMDS 9.0 kompatibel und kann nur damit arbeiten“), daher wird UMDS zusammen mit vCenter aktualisiert. Offline-Bundles, die ZIP-Dateien von Broadcom oder dem Serverhersteller, werden in das Depot importiert, während „Lifecycle Manager ab vCenter 9.0 den Import von ISO-Dateien nicht mehr unterstützt“ (KB 419331). Für Außenstellen mit eingeschränkter Verbindung zu vCenter verweist ein Depot-Override einen Cluster oder eigenständigen Host auf ein lokales Depot.

So stellen Sie einen Cluster von Baselines auf ein Image um

Die Reihenfolge unten stammt von uns; die Bezeichnungen in der Oberfläche kommen aus Broadcoms Handbüchern zu 8.0 und 9.0, aktualisiert zwischen Juli und September 2026, und entsprechen dem Handbuch zu 9.1 vom 29. September 2026.

1. Importieren Sie das Basis-Image des aktuellen Builds der Hosts, das Hersteller-Add-on und die Komponenten von Drittanbietern in das Depot; registrieren Sie den Hardware Support Manager, wenn das Image Firmware enthalten soll.
2. Wählen Sie den Cluster aus, öffnen Sie die Registerkarte Updates und klicken Sie auf Image (vCenter 8.0) oder Image Setup (vCenter 9.0); zuerst läuft die Eignungsprüfung.
3. Wählen Sie die Quelle: das Image eines Hosts mit Proceed with selected image (8.0) oder Proceed with this image (9.0), eine JSON-Datei, unter 9.0 ein Image aus der Image Library oder Set up image manually.
4. Gleichen Sie das Image mit dem ab, was heute läuft: ESXi Version, Hersteller-Add-on, Firmware- und Treiber-Add-on sowie die Komponenten unter Show details und Add components.
5. Klicken Sie auf Validate, dann auf Save; es folgt eine Compliance-Prüfung, und unter 9.0 bietet die Karte Step 2: Check Image Compliance Check compliance an.
6. Klicken Sie auf Finish image setup und bestätigen Sie mit Yes, finish image setup; ab hier bleibt der Cluster bei Images.
7. Führen Sie den Pre-Check vor der Remediation aus, remediieren Sie in einem Wartungsfenster einen ausgewählten Host, prüfen Sie ihn und remediieren Sie dann die übrigen.
8. Wiederholen Sie den Wechsel für jeden eigenständigen Host, vSAN-Witness-Hosts eingeschlossen, mit Use image on host oder einem manuell eingerichteten Image.

Unsere VMware-Optimierung modernisiert vSphere, vSAN und NSX in vereinbarten Wartungsfenstern, Schritt für Schritt, mit einem Rollback-Plan für jede Etappe. Nennen Sie uns, wie viele Cluster noch mit Baselines laufen und welche Servermodelle jeder davon enthält.

Umstellung von Baseline auf Image scheitert: Fehler und Lösungen

Broadcoms Wissensdatenbank dokumentiert diese Fehler für Umgebungen mit vCenter 8.x oder VCF 5.2. KB 444420, deren Titel mit „Unable to convert cluster from baseline to vLCM image due to NSX-T validation error“ beginnt, behandelt die erste Zeile; die vollständige Meldung beginnt mit „Cannot determine whether NSX-T Data Center is enabled on this cluster.“

Broadcom KB 444420, 445081, 419651, 443602, 446633 und 390121, Stand Oktober 2026.

Für die Lösung aus KB 446633 melden Sie sich per SSH als root an der vCenter-Appliance an, bearbeiten /etc/sysconfig/proxy und führen dann /etc/init.d/proxy restart und vmon-cli -r updatemgr aus.

VCF, gemischte Hardware, Supervisor und eigenständige Hosts

In VCF müssen Cluster und eigenständige Hosts, die SDDC Manager verwaltet, „ausschließlich über von SDDC Manager unterstützte Mechanismen“ umgestellt werden. KB 385617 verweist auf ein PowerShell-Skript, das Broadcom empfiehlt, und auf die API von SDDC Manager, beide für VCF 5.2.2 und 9.0.x. Laut README des Skripts kommen Supervisor-Cluster ab VCF 9.0 und eigenständige Hosts ab 9.1 hinzu. Sobald SDDC Manager auf 9.0 steht, wechselt jeder Cluster in der Management-Domain und in den Workload-Domains vor ESX 9.0 auf Images; wo das nicht möglich ist oder vSphere Supervisor aktiviert ist, sieht Broadcom den Wechsel nach dem vCenter-Upgrade und vor dem ESX-Upgrade vor.

Unter VCF 9.0.x zeigt vCenter das Banner „Transition from vLCM Baselines to vLCM Images in a VCF environment should be performed via SDDC manager only.“ KB 422298 beschreibt, wie es sich in SDDC Manager abschalten lässt, etwa bei Greenfield-Installationen von VCF 9.1, wo es erscheinen kann, obwohl kein Cluster Baselines verwendet. In einer Standard-vCenter-Umgebung ist es laut KB 341192 „völlig unbedenklich, mit dieser Umstellung fortzufahren“. Der VCF Installer 9.0 weist Baseline-Cluster mit „Cluster is not vSphere Lifecycle Manager (vLCM) image based“ zurück (KB 443265), was für den Converge-Weg in unserem Vergleich von VVF und VCF wichtig ist.

Für gemischte Hardware sagt Broadcoms Handbuch zu 9.0: „Solche Cluster müssen zuerst auf ESX 9.0 aktualisiert, dann auf Images umgestellt und mit einem Composite Image verwaltet werden“, während vCenter 9 ISO-Upgrades bei Baselines blockiert. KB 424294 nennt zwei Wege, die Beschränkung von Update Manager vorübergehend aufzuheben: ein Skript für VCF PowerCLI oder einen Aufruf aus dem API Explorer im Developer Center von vCenter. Die Änderung gilt, bis „der Dienst neu gestartet oder die vCenter-Appliance neu gebootet wird“, und nach dem Upgrade auf ESX 9 sollen diese Cluster laut Broadcom „umgehend“ auf Images wechseln. Welche Hosts ESX 9 ausführen können, steht in unserem Leitfaden zu den Hardware-Anforderungen für ESX 9. Der vSAN-Witness-Host, der einen Stretched Cluster oder bis zu 64 Zwei-Knoten-Cluster bedient, wird wie jeder andere eigenständige Host umgestellt und aktualisiert.

Unser Umgebungs- und Lizenz-Audit erstellt eine vollständige Inventur Ihrer VMware-Umgebung: Versionen, Abonnements, tatsächliche Ressourcennutzung und Risikoprofil. Beschreiben Sie Ihre vCenter-Instanzen und Cluster im Formular unten, mit SDDC Manager, NSX oder Supervisor, wo diese laufen.

Nach der Umstellung: Compliance, Remediation und Grenzen des Rollbacks

Der Abschluss der Einrichtung lässt die Hosts unverändert: „Der bloße Wechsel der Verwaltungsmethode verändert weder die Hosts im Cluster noch den eigenständigen Host.“ Die Karte Image Compliance zeigt danach jeden Host als konform, nicht konform, inkompatibel (das Image „kann nicht auf den Host angewendet werden“) oder unbekannt an. Hosts werden „standardmäßig nacheinander remediiert“ und gehen in den Wartungsmodus, wenn das Update es erfordert; ein fehlgeschlagener Host stoppt die Remediation des Clusters, sofern keine parallele Remediation konfiguriert ist. Die erste Remediation löscht eigenständige VIBs und die Agenten nicht integrierter Lösungen.

Für den Cluster gibt es keinen Weg zurück zu Baselines. Wird vCenter aus einem Backup von vor dem Wechsel wiederhergestellt, enthält die wiederhergestellte Instanz laut Broadcoms Handbuch zu 9.0 den Cluster, „aber Sie müssen ihn wieder mit Baselines verwalten“. Nach einer Wiederherstellung auf einen Stand vor einem Image-Upgrade sind die Hosts mit dem älteren Image inkompatibel, und „da Sie ESX nicht downgraden können“, besteht die Abhilfe darin, das Cluster-Image auf die Version anzuheben, die auf den Hosts läuft. Exportieren Sie nach dem Wechsel jedes Image und erstellen Sie ein neues vCenter-Backup. vCenter 9.0 verwaltet ESX-8.0-Hosts (KB 424129), daher kann ein imagebasiert verwalteter Cluster auf einem Basis-Image von ESXi 8.0 Update 3 bleiben, bis seine Hosts aktualisiert oder ersetzt werden.

Was wir tun

Eurokommerz hält den Vertrag; die technische Umsetzung übernimmt unser Engineering-Partner Vixen.UNO. Im Rahmen der VMware-Optimierung gehört der Wechsel von Baselines zu Images zur Modernisierung von vSphere, vSAN, NSX und VCF, umgesetzt in vereinbarten Wartungsfenstern mit einem Rollback-Plan für jede Etappe. Das erste Gespräch ist kostenlos; das kostenpflichtige technische Assessment, dessen Preis vor Beginn der Arbeiten feststeht, liefert einen Bericht, ein TCO- und ROI-Modell und einen Maßnahmenplan vor Renewal und End of Support, mit Terminen. Nach dem Projekt läuft der Support unter einem vereinbarten SLA weiter.

FAQ