Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Cross vCenter vMotion ist eine native VMware-Funktion. Sie ermöglicht die Live-Migration laufender virtueller Maschinen (VMs) zwischen unterschiedlichen vCenter Server-Instanzen ohne Ausfallzeiten. Im Gegensatz zum herkömmlichen vMotion, das VMs innerhalb eines einheitlichen Verwaltungsclusters verschiebt, durchbricht diese Technologie Verwaltungsgrenzen und ermöglicht eine flexible Ressourcenplanung.
In der Unternehmenspraxis ist die Abgrenzung zweier Begriffe unerlässlich:
Das eigentliche Ziel besteht darin, Anwendungen während der Infrastrukturumstellung durchgehend verfügbar zu halten. Die native Streaming-Funktion von VMware ist zwar eine praktische Lösung, aber nur eine von mehreren möglichen Methoden, um dieses Ziel zu erreichen.
Die meisten Unternehmensprojekte zielen auf die Migration von Workloads zwischen vCenter-Instanzen ab. Nutzer sollten daher je nach vorhandener Umgebung die passende Lösung auswählen und sich nicht ausschließlich auf das native vMotion beschränken.
Auf Hypervisor-Ebene handelt es sich bei Cross vCenter vMotion um eine „Shared-Nothing“-Migration. Es werden Workloads zwischen isolierten Umgebungen kopiert, ohne gemeinsame Speicherarrays vorauszusetzen. Gleichzeitig werden zwei Datenströme über das Netzwerk synchronisiert:
Sobald die Datensynchronisation abgeschlossen ist, wird die virtuelle Netzwerkschnittstelle (vNIC) sofort auf das Zielnetz umgeschaltet – ohne Unterbrechung der Anwendungen.
Die Verwaltung dieses Vorgangs hängt von der Verknüpfung der vCenter-Server ab:
Sowohl im Standard- als auch im erweiterten Modus ist das native vMotion stark auf eine durchgängig einheitliche Infrastruktur angewiesen. Diese strenge Anforderung an eine „perfekte VMware-Umgebung“ ist der Hauptgrund für Fehler und Ausfälle bei Migrationen in realen Unternehmensumgebungen.
Das native Cross vCenter vMotion funktioniert wie eine Kette: Scheitert ein einzelnes Glied, wird die gesamte Migration abgebrochen. Um die automatisierten Vorprüfungen zu bestehen, müssen beide Umgebungen gleichzeitig folgende strengen Kriterien erfüllen:
In komplexen Unternehmensumgebungen ist eine vollständige Einheitlichkeit kaum erreichbar. Bei nicht vertrauenswürdigen Active-Directory-Domänen, abweichenden Patch-Ständen, WAN-Verbindungen mit hoher Latenz oder alternativen Hypervisoren fallen diese nativen Voraussetzungen vollständig weg – das native vMotion ist dann nicht nutzbar.
Je nach Umfang der Workload-Verlagerung kann eine Cross-vCenter-Migration entweder über die vSphere Client-Oberfläche oder mittels automatisierter Skripte nativ ausgeführt werden.
Geeignet für einmalige Migrationen einer begrenzten Anzahl von Workloads über den nativen grafischen Assistenten im vSphere Client.
Schritt 1: Assistent zum Export starten
Melden Sie sich am Quell-vSphere Client an, klicken Sie mit der rechten Maustaste auf die virtuelle Maschine, wählen Sie Migrieren aus, markieren Sie die Option „Export zwischen vCenter-Servern“ und klicken Sie auf Weiter.
Schritt 2: Authentifizierung des Remote-vCenter
Geben Sie den FQDN oder die IP-Adresse des Ziel-vCenter ein, tragen Sie die Administrator-Zugangsdaten ein (z. B. administrator@vsphere.local) und bestätigen Sie den SSL-Zertifikat-Fingerabdruck.
Schritt 3: Auswählen der Ziel-Rechenressourcen und Ausführen der Vorprüfungen
Navigieren Sie im Ziel-Inventarbaum und wählen Sie den Ziel-Cluster, den Ressourcenpool oder den Host aus. Warten Sie, bis die Prüfmaschine die Meldung „Kompatibilitätsprüfungen bestanden“ anzeigt.
Schritt 4: Zuordnung von Speicher und Netzwerken sowie Ausführung der Migration
Wählen Sie den Ziel-Datastore aus, ordnen Sie die virtuellen Netzwerkadapter (vNICs) der Quelle manuell den Ziel-Portgruppen zu, überprüfen Sie die Zusammenfassung und klicken Sie auf Fertigstellen.
Für großangelegte automatisierte Massenmigrationen zwischen unverbundenen vCenter-Instanzen werden VMware PowerCLI-Skripte verwendet.
Schritt 1: Herstellen einer Verbindung zu beiden unabhängigen vCenter-Server-Sitzungen
$SourceVC = Connect-VIServer -Server "source-vc.domain.local" -User "admin@vsphere.local" -Password "SourcePass123!"
$TargetVC = Connect-VIServer -Server "target-vc.domain.local" -User "admin@vsphere.local" -Password "TargetPass123!"
Schritt 2: Definieren und Zuweisen der Inventarvariablen für die Migration
$VMToMigrate = Get-VM -Name "Prod-App-Server-01" -Server $SourceVC
$TargetHost = Get-VMHost -Name "esxi-host-01.target.local" -Server $TargetVC
$TargetDS = Get-Datastore -Name "Target_SAN_Datastore_01" -Server $TargetVC
$TargetPortGd = Get-VirtualPortGroup -Name "VLAN-200-Target-Net" -Server $TargetVC
Schritt 3: Ausführen der automatisierten VM-Verschiebung zwischen Instanzen mit Move-VM
Move-VM -VM $VMToMigrate `
-Destination $TargetHost `
-Datastore $TargetDS `
-NetworkAdapter $VMToMigrate.NetworkAdapters[0] `
-PortGroup $TargetPortGd `
-Server $SourceVC `
-Confirm:$false
Auf dem Papier erscheinen diese Arbeitsabläufe unkompliziert, in der Praxis treten jedoch häufig unerwartete Probleme während des Migrationsfensters auf – beispielsweise Firewalls, die Port 8000 blockieren, nicht routbare VMkernel-Segmente oder abweichende Host-Patch-Stände.
Letztendlich stellt sich heraus, dass native Arbeitsabläufe ausschließlich für „perfekte“ VMware-Umgebungen ausgelegt sind und die komplexen Realitäten von Unternehmensmigrationen zwischen vCenter-Instanzen kaum berücksichtigen.
Ein Ausfall von Cross vCenter vMotion geht meist mit spezifischen Fehlermeldungen einher, die auf die strengen Voraussetzungen zurückzuführen sind. Die Behebung erfordert jedoch oft mehr als einfache Einstellungsänderungen, sondern die Lösung tieferliegender Infrastrukturbeschränkungen.
Ursache: Die dedizierten vMotion-VMkernel-Ports auf Quell- und Ziel-ESXi-Host können keine Pakete über TCP 8000 gegenseitig routen.
Lösung: Aktivieren Sie SSH auf dem Quellhost und führen Sie einen bidirektionalen vmkping-Test zur Überprüfung der Layer-3-Routing-Verbindung zur vMotion-IP des Ziels aus:
vmkping -I vmk1 [Ziel-vMotion-IP]
Schlägt dieser Test fehl, isolieren physische Netzwerke, Firewalls oder VLAN-Tags den vMotion-Datenverkehr.
Ursache: Der Ziel-ESXi-Host verfügt über eine ältere oder inkompatible CPU-Architektur oder unterstützt die Hardware-Version der Quell-VM nicht.
Lösung: Konfigurieren Sie den Enhanced vMotion Compatibility (EVC)-Modus auf dem Zielcluster, um die CPU-Baseline abzusenken, oder legen Sie eine VM-spezifische EVC-Maske fest, bevor Sie den Assistenten starten.
Ursache: Die Zeitdifferenz zwischen den beiden unabhängigen vCenter-Appliances überschreitet das sichere SAML-Token-Authentifizierungsfenster von 5 Minuten.
Lösung: Melden Sie sich über die Appliance-Verwaltungsoberfläche (VAMI unter `https://vcenter-ip:5480`) an beiden vCenter-Instanzen an. Synchronisieren Sie beide vCenter-Server mit demselben unternehmensweiten NTP-Stratum-Server.
Diese Fehler sind meist Folgen unveränderbarer Infrastrukturgrenzen und keine bloßen Konfigurationsfehler. Wenn Sicherheitsrichtlinien die Öffnung von Port 8000 zwischen Rechenzentren verbieten oder Alt-Hardware keine aktuellen EVC-Baselines unterstützt, stößt die herkömmliche Fehlerbehebung an ihre Grenzen.
Da diese Blockaden konstruktionsbedingte Einschränkungen des nativen Frameworks sind, muss zur Lösung von Projektengpässen vollständig auf das native vMotion verzichtet werden.
Die herkömmliche Fehlerbehebung versagt, wenn native vMotion-Fehler aus unveränderbaren Infrastrukturgrenzen statt einfacher Konfigurationsfehler resultieren. Sollten Sicherheitsrichtlinien die Öffnung von Port 8000 zwischen Rechenzentren verbieten oder Alt-Hardware keine aktuellen EVC-Baselines unterstützen, müssen die zentralen betrieblichen Einschränkungen des nativen Systems berücksichtigt werden:
Zusammenfassend ist das native vMotion nur eine spezielle Einzelfunktion und keine ganzheitliche Migrationsstrategie. Unternehmensumgebungen benötigen ein umfassendes Framework für Cross-vCenter-Migrationen, das unabhängig von Hypervisor-Versionen, strengen Domänenvertrauensstellungen oder Netzwerkeinschränkungen funktioniert.
Wenn native Hypervisor-Einschränkungen ein Projekt blockieren, benötigen Organisationen eine unternehmensgeeignete Live-Migrationsplattform, die die Replikation von der Virtualisierungsebene entkoppelt. i2Migration erfüllt diese Anforderung für komplexe Cross-vCenter- und plattformübergreifende Umstellungen.
Keine Abhängigkeit von SSO-Domänen: Wird innerhalb des Gast-Betriebssystems ausgeführt, sodass verbundene SSO-Domänen, gemeinsame Zugangsdaten oder gekoppelte SSL-Zertifikate zwischen vCenter-Instanzen entfallen.
Keine Hardware-Einschränkungen: Umgeht Hypervisor-Kompatibilitätsprüfungen und ermöglicht Migrationen auf abweichende CPU-Generationen ohne EVC-Baselines.
Optimiert für WAN-Verbindungen: Nutzt bytegenaue Änderungsverfolgung und Datenkompression, um Replikations-Timeouts bei Verbindungen mit hoher Latenz oder geringer Bandbreite zu vermeiden.
Plattformübergreifende Flexibilität: Löst die Bindung an einen Hypervisor, unterstützt Umstellungen zwischen gemischten vSphere-Versionen, alternativen Hypervisoren (KVM, Nutanix AHV, Proxmox VE) und gängigen öffentlichen Clouds.
Minimale Geschäftseinbußen: Hintergrundsynchronisation gewährleistet unbeeinträchtigte Produktionsleistung, ein schneller Umschaltvorgang beschränkt das endgültige Ausfallfenster auf wenige Sekunden.
Nein. VHD und VHDX sind Microsoft Hyper-V-Formate, VMware nutzt ausschließlich VMDK. Die Umwandlung zwischen Microsoft- und VMware-Festplattenformaten erfordert ein spezialisiertes plattformübergreifendes Tool, keinen nativen vMotion-Arbeitsablauf.
Ja, standardmäßig. Das Ziel-vCenter weist nach der Migration eine neue MAC-Adresse zu. Wenn Ihre Anwendung an eine fest vergebene Lizenz gebunden ist, legen Sie vor der Migration eine statische MAC-Adresse für den Netzwerkadapter fest.
Ja, innerhalb der unterstützten Versionsgrenzen. Der erweiterte Cross vCenter vMotion ermöglicht die direkte Migration von Workloads aus vSphere 7.0 oder 8.0 in eine neue vSphere 9.0-Infrastruktur, vorausgesetzt die Zielhosts unterstützen die VM-Hardware-Version.
Das native Cross vCenter vMotion funktioniert einwandfrei in standardisierten VMware-Umgebungen. i2Migration hingegen löst alle Probleme von realen Cross-vCenter-Migrationen, die durch Versionsunterschiede, WAN-Latenz und plattformübergreifende Anforderungen entstehen, und stellt eine zuverlässige unternehmensgeeignete Migrationslösung dar.
· Unternehmenskunden und Mittelstand weltweit
· Unser Support-Team unterstützt Sie während der gesamten Testphase
· Starten Sie eine 60-tägige Testversion oder sehen Sie sich eine Demo an, um zu erfahren, wie Info2Soft Unternehmensdaten schützt.
