vCenter-Server konsolidieren: Hosts, VMs und SSO-Domänen zwischen vCenter-Instanzen verschieben

So konsolidieren Sie vCenter-Server

Um vCenter-Server zu konsolidieren, legen Sie fest, welches vCenter bleibt, und verschieben dann die Workloads auf einem von zwei Wegen darunter: Sie verschieben die VMs mit Cross vCenter vMotion oder Advanced Cross vCenter vMotion, oder Sie verschieben ganze ESXi-Hosts, indem Sie sie aus einem Inventar entfernen und dem anderen hinzufügen. Ein geleertes vCenter wird außer Betrieb genommen, sobald seine Backups, sein Monitoring und seine Lizenzen umgezogen sind. Ein dritter Vorgang, der Repoint der Single-Sign-On-Domäne (SSO) in vSphere 8, fasst vCenter in einer Domäne zusammen, ohne einen Host zu verschieben. In 9.x empfiehlt Broadcom statt Enhanced Linked Mode die vCenter-Verknüpfung (vCenter Linking) in VCF Operations; auch sie lässt jedes Inventar, wo es ist.

Welche Methode passt, hängt davon ab, ob die Hardware bleibt, ob vSAN läuft und wie lange VMs ausfallen dürfen.

Broadcom KB 344959, KB 337625, KB 326849 und KB 450887; Dokumentation zu vSphere 8.0 über Advanced Cross vCenter vMotion und über das Repointing von Domänen, gelesen am 10. Oktober 2026. Die Spalte zur Ausfallzeit ist unsere Lesart dessen, was jede Quelle angibt.

VMs verschieben oder Hosts verschieben

Das Verschieben von VMs passt zu einer Konsolidierung, die zugleich die Hardware ersetzt, wobei jede VM im laufenden Betrieb umzieht. Es braucht geroutete Pfade für vMotion und Provisioning zwischen den Clustern sowie Ziel-CPUs desselben Herstellers; den Wechsel von älteren auf neue Hosts behandelt unser Leitfaden zum Austausch von ESXi-Hosts. Ein Umzug, der auch den Datenspeicher wechselt, zählt als vMotion ohne gemeinsam genutzten Speicher, den die Grenzwerte von vSphere 8.0 auf 2 gleichzeitige Vorgänge je Host begrenzen. Das Verschieben von Hosts passt zu Hardware, die in Betrieb bleibt und bei der sich nur das verwaltende vCenter ändert. Es braucht keine Kopierzeit, berührt aber Distributed Switches, HA, DRS und die vSAN-Mitgliedschaft.

Als Beispiel dienen 40 Hosts unter drei vCenter nach zwei Übernahmen: 24 Hosts mit vSAN unter dem vCenter, das bleibt, 10 Hosts an einem SAN unter einem zweiten vCenter in einer eigenen SSO-Domäne und 6 ältere Hosts unter einem dritten. Die 10 SAN-Hosts können als Hosts in einen neuen Cluster des verbleibenden vCenter umziehen. Die VMs der 6 älteren Hosts verschieben Sie besser mit Advanced Cross vCenter vMotion in die bestehenden Cluster, sofern beide Seiten denselben CPU-Hersteller nutzen; danach werden diese Hosts ausgemustert. Die Aufteilung der 34 verbleibenden Hosts in Cluster behandelt unser Artikel zum Design von vSphere-Clustern für 10 bis 60 Hosts.

Voraussetzungen für Cross vCenter vMotion bei einer Konsolidierung

Klassisches Cross vCenter vMotion verlangt beide vCenter im Enhanced Linked Mode, also eine gemeinsame SSO-Domäne. Broadcoms KB 344959 ergänzt, dass beide vCenter „miteinander zeitsynchronisiert sein müssen“, dass Quelle und Ziel „dieselbe Version haben sollten“ und dass die Funktion eine Enterprise-Plus-Lizenz erfordert. Über die vSphere APIs dürfen die beiden vCenter in getrennten SSO-Domänen liegen.

Advanced Cross vCenter vMotion „hängt nicht von vCenter Enhanced Linked Mode oder Hybrid Linked Mode ab“ und ist damit das Werkzeug für vCenter in verschiedenen Domänen. Broadcoms Dokumentation zu vSphere 8.0 verlangt, dass das vCenter, von dem aus Sie den Import oder Export starten, 7.0 Update 1c oder neuer ausführt, das Quell-vCenter und die Ziel-ESXi-Hosts 6.7 oder neuer, dazu das Privileg Resource.Query vMotion. Laufende VMs brauchen eine Lizenz für vSphere Enterprise Plus auf beiden vCenter; ausgeschaltete VMs brauchen vSphere Standard. Wenn Sie mehrere VMs in einem Vorgang importieren, „müssen die ausgewählten virtuellen Maschinen denselben Betriebszustand haben“; planen Sie die Chargen daher nach Betriebszustand.

KB 344959 setzt außerdem zwei Grenzen im Netzwerk. Das Verschieben einer VM von einem Distributed Switch auf einen Standard-Switch wird nicht unterstützt, und Cross vCenter vMotion „wird mit Switches von Drittanbietern nicht unterstützt“. Legen Sie die Ziel-Portgruppen auf einem Distributed Switch an, bevor die erste Charge umzieht. Ports und Umzüge zu einem Provider behandelt unser Leitfaden zur VM-Migration in eine VMware-Cloud.

ESXi-Hosts in ein anderes vCenter verschieben: Distributed Switch und vSAN

Broadcoms KB 337625 hält fest, dass „Hosts die vDS-Konnektivität während eines Inventarumzugs nicht aufrechterhalten können“. Das Verfahren beginnt mit Voraussetzungen: HA wird vor dem Umzug im neuen vCenter neu angelegt, „DRS muss auf manuell gesetzt oder deaktiviert werden“, und Storage DRS wird auf manuell gesetzt, mit am Ziel duplizierter Konfiguration. Auch die DRS-Einstellungen werden am Ziel neu angelegt, und der Host verliert seine Ressourcenpools. Die Schritte sind dann:

1. Sichern Sie die Konfiguration des Distributed Switch.
2. Legen Sie auf dem Host einen Standard-Switch für VMs, VMkernel-Adapter und Management-Verkehr an und verlegen Sie das Netzwerk des Hosts dorthin.
3. Entfernen Sie den Host aus dem Cluster im Quell-vCenter.
4. Fügen Sie den Host dem Ziel-vCenter hinzu.
5. Legen Sie die Distributed Switches im Ziel-vCenter an oder importieren Sie sie.
6. Verlegen Sie das Netzwerk des Hosts vom Standard-Switch zurück auf den Distributed Switch.

Nutzt der Ziel-Cluster EVC, sagt die KB, „alle VMs auszuschalten, bevor der Host hinzugefügt wird“.

Ein vSAN-Cluster braucht weitere Schritte. KB 326849 verlangt ein Ziel-vCenter „mit einer Build-Version, die gleich oder höher als die Version der ESXi-Hosts ist“, einen neuen Cluster, angelegt „mit deaktiviertem DRS und vSphere HA“, vSAN aktiviert mit den Diensten des ursprünglichen Clusters, die KMS-Server unter denselben Namen, wo Verschlüsselung läuft, und Speicherrichtlinien, die „den vSAN-Richtlinien des alten Clusters entsprechen“, sonst kann vSAN neu synchronisieren. Bevor die Hosts getrennt werden, wird IgnoreClusterMemberListUpdates auf 1 gesetzt, damit sie ihre Unicast-Konfiguration behalten. Sie ziehen nacheinander um, jeder zuerst außerhalb des Clusters hinzugefügt und dann in ihn verschoben, mit einer Prüfung der Mitgliederzahl. Wird ein Host direkt in den Cluster aufgenommen, erzwingt das den Wartungsmodus, was „sich negativ auf laufende VMs auswirken kann“. Wenn alle Hosts aufgenommen sind, geht die Einstellung zurück auf 0. Die KB unterstützt den Umzug eines Clusters mit vSAN File Service nicht und verlangt, einen Stretched Cluster vorher aufzulösen.

Unser Engineering-Partner Vixen.UNO führt clusterübergreifende Migrationen in vereinbarten Wartungsfenstern durch, mit einem Rollback-Plan für jede Etappe. Beschreiben Sie Ihre vCenter, Cluster und Switch-Typen im Formular unten, auch welche Cluster vSAN nutzen.

SSO-Domänen-Repoint in vSphere 8

Der Repoint verschiebt ein vCenter in eine bestehende oder eine neue SSO-Domäne, ab vCenter 6.7 Update 1. Broadcoms Dokumentation zu vSphere 8.0 verlangt, dass das Ziel „dieselbe Version“ hat und die Knoten „dieselbe Version und Build-Nummer“, und vorher ein dateibasiertes Backup jedes Knotens. Der Befehl lautet cmsso-util domain-repoint und läuft als root auf der Appliance in zwei Modi. Pre-check „migriert keine Daten, prüft aber auf Konflikte“ und liest Tags, Kategorien, Rollen und Privilegien aus; für jeden Konflikt wählen Sie Copy, Skip oder Merge. Execute importiert sie, und „Dienste wie Tagging und Lizenzierung bleiben erhalten und werden in die neue Domäne migriert.“

KB 450887 listet auf, was der Repoint nicht überträgt. Weil „die vmdir-Struktur neu erstellt wird“, werden globale Berechtigungen, eigene lokale SSO-Benutzer und -Gruppen sowie Identitätsquellen zuerst dokumentiert und danach neu angelegt, der Beitritt zum Verzeichnisdienst wird wiederholt, und externe Lösungen wie NSX werden erneut registriert. Für vCenter im Enhanced Linked Mode verlangt die KB „einen gleichzeitigen, ausgeschalteten (Offline-)Snapshot aller vCenter-Server-Knoten“ und stellt zuerst den ersten Knoten um, dann die übrigen gegen einen bereits umgestellten Replikationspartner. Dieselbe KB hält fest: „Domänenübergreifendes Repointing wird in Umgebungen mit VMware Cloud Foundation (VCF) nicht unterstützt.“ Das Backup selbst behandelt unser Leitfaden zu vCenter-Backup und Wiederherstellung.

Enhanced Linked Mode und vCenter-Verknüpfung in 9.x

Broadcoms Release Notes zu VCF 9.0 (Hinweise zur vSphere-Unterstützung, aktualisiert am 29. September 2026) halten fest, dass Enhanced Linked Mode mit vCenter 9.0 „veraltet ist und in einem künftigen Release entfernt wird“. Wir haben kein Broadcom-Dokument gefunden, das dieses Release nennt. Dieselben Notes sagen, dass ELM „in vCenter 9.0 unterstützt wird, um ein reibungsloses Upgrade bestehender Infrastruktur auf VCF zu ermöglichen“, mit „der Gruppierungsfunktion in VCF Operations“ als empfohlener Alternative. Broadcoms KB 436011 für vSphere Foundation 9.x ersetzt ein ELM-Setup so: ausgeschaltete Snapshots der vCenter-VMs, cmsso-util break-elm, derselbe Identitätsanbieter auf jedem vCenter, dann die Verknüpfung in VCF Operations. Die KB weist darauf hin, dass „Berechtigungen von IDP-Benutzern nicht zwischen vCenter-Systemen geteilt werden“; Berechtigungen werden daher auf jedem vCenter gesetzt.

Broadcoms VCF-Blog vom 2. Juni 2026 sagt, dass ELM „bis zu 15 vCenter-Server-Appliances“ in einer SSO-Domäne verbindet, während die vCenter-Verknüpfung „die Anforderung aufhebt, dass alle verknüpften vCenter-Instanzen exakt dieselben Builds ausführen“. „Die wichtigste Voraussetzung ist vCenter 9.0 oder neuer“, und die Anmeldung läuft über VCF SSO mit einem externen OIDC- oder SAML-Identitätsanbieter. Eine Konsolidierung in 9.x verschiebt daher weiterhin VMs oder Hosts. Broadcoms Regeln, um bestehende vCenter per Converge oder Import in eine VCF-Instanz zu übernehmen, stehen in unserem Vergleich von VVF und VCF.

Lizenzen, Berechtigungen, Backup-Jobs und Monitoring nach dem Umzug

In 8.x brauchen Hosts, die für sich allein umziehen, ihre Lizenzschlüssel im Ziel-vCenter. Für 9.1 sagt Broadcoms Lizenzierungsdokumentation (aktualisiert am 8. Oktober 2026): „Sie weisen Lizenzen vCenter-Instanzen zu“, über VCF Operations, und „Die einzigen Assets in Ihrer Umgebung, die die Kapazität Ihrer primären Lizenzen verbrauchen, sind ESX-Hosts.“ Ein Host, der ohne freie Kapazität hinzugefügt wird, „bleibt bis zu 90 Tage im Evaluierungsmodus“, und „Der Evaluierungszeitraum beginnt mit der Installation von ESX, nicht mit dem Hinzufügen zur vCenter-Instanz.“ Ein vor langer Zeit installierter Host hat daher womöglich keine Evaluierungszeit mehr, und ein Host mit abgelaufener Evaluierung wird vom vCenter getrennt. Prüfen Sie die Kapazität des Ziel-vCenter, bevor der erste Host ankommt.

Rollen, Berechtigungen, Alarmdefinitionen, Tags, Inhaltsbibliotheken und Ordner gehören zum Quell-vCenter oder zu seiner SSO-Domäne, nicht zu den Hosts; dokumentieren Sie sie daher und legen Sie sie am Ziel neu an, bevor VMs eintreffen.

Veeams Benutzerhandbuch für Version 13, zu dem seine KB 2136 inzwischen führt, sagt, dass Veeam Backup & Replication „VMs in Jobs über Managed Object Reference IDs (MORef-IDs) verfolgt, die sich nach einer Migration oder Neuerstellung von vCenter ändern“, und nennt das Dienstprogramm VM Migrator in seinem PowerShell-Modul, um die Abweichung aufzulösen. Veeams PowerShell-Referenz verlangt ein Konfigurations-Backup, bevor das Dienstprogramm genutzt wird, und sagt, Backup-Jobs für VMs aus dem neuen vCenter erst auszuführen, wenn die Arbeit damit abgeschlossen ist. Planen Sie die Änderungen an den Jobs vor der Umstellung. Monitoring, Skripte und Dienstkonten, die auf das alte vCenter zeigen, ziehen ebenfalls um, und die alte Appliance bleibt eingeschaltet, bis nichts sie mehr abfragt.

Plan für die vCenter-Konsolidierung

1. Erfassen Sie jedes vCenter: Version und Build, SSO-Domäne, ELM-Status, Cluster, CPU-Hersteller und EVC-Modus, Switch-Typ, vSAN-Dienste, Lizenzen und registrierte Lösungen.
2. Wählen Sie das Ziel-vCenter und die Cluster-Aufteilung und entscheiden Sie je Cluster, ob Hosts oder VMs umziehen.
3. Bauen Sie die Zielseite auf: Distributed Switches und Portgruppen, Speicherrichtlinien, Rollen, Berechtigungen, Tags und Ordner.
4. Erstellen Sie dateibasierte Backups aller vCenter, exportieren Sie jeden Distributed Switch und bestätigen Sie den Weg zur Wiederherstellung.
5. Verschieben Sie einen Pilot-Cluster oder eine Charge unkritischer VMs und prüfen Sie daran HA, DRS, Backups und Monitoring.
6. Verschieben Sie die übrigen Cluster oder VM-Chargen in vereinbarten Wartungsfenstern, geordnet nach den Abhängigkeiten der Anwendungen.
7. Stellen Sie Backup-Jobs, Monitoring und Automatisierung um und prüfen Sie die Lizenzkapazität am Ziel.
8. Nehmen Sie das leere vCenter nach einem letzten Backup außer Betrieb und entfernen Sie es aus dem DNS, dem Identitätsanbieter und den registrierten Lösungen.

Eine mit Advanced Cross vCenter vMotion verschobene VM kann zurückziehen, solange beide vCenter laufen, und ein Host kann zu seinem alten vCenter zurückkehren, solange dieses vCenter und seine Switch-Konfiguration existieren. Ein Repoint wird aus dem dateibasierten Backup oder, im ELM, aus den Offline-Snapshots zurückgerollt.

Das Umgebungs- und Lizenz-Audit unserer VMware-Optimierung erfasst Versionen, Subscriptions und tatsächliche Ressourcennutzung jedes vCenter, das Sie betreiben. Schicken Sie uns Ihr vCenter-Inventar über das Formular unten, mit den Builds, den SSO-Domänen und dem vCenter, das Sie behalten würden.

Was wir tun

Unsere VMware-Optimierung beginnt mit einem Umgebungs- und Lizenz-Audit von Versionen, Subscriptions und tatsächlicher Ressourcennutzung. Host- und Cluster-Konsolidierung gehört zu ihrer Lizenz- und Kostenoptimierung, und unser Engineering-Partner Vixen.UNO führt die clusterübergreifenden Migrationen in vereinbarten Wartungsfenstern durch, Schritt für Schritt, mit einem Rollback-Plan für jede Etappe. Danach folgt Support unter einem vereinbarten SLA, und der Preis der technischen Bewertung wird vor Beginn der Arbeiten festgelegt.

FAQ