VM-Migration in die Cloud: VMware-Methoden, Ausfallzeit, Netzwerkänderungen und Rückfallplan

VMware-Migrationsmethoden für den Umzug von VMs in die Cloud

Eine VM-Migration auf eine gehostete VMware-Plattform kann eine der vier hier verglichenen Methoden nutzen: eine kalte Kopie (OVF-Export und -Import oder ein Cross-vCenter-Umzug der ausgeschalteten VM), Replikation mit einem Veeam Planned Failover, Cross vCenter vMotion im laufenden Betrieb oder VMware HCX, das Replikation, vMotion und Network Extension kombiniert. Die Ausfallzeit reicht von null bei Live-Methoden bis zur gesamten Kopierdauer bei kalten Methoden; jede Methode braucht andere Lizenzen, Netzwerkpfade und Zugriffe auf die Plattform des Providers, und eine Migration kann sie je Welle von VMs kombinieren. Wo beide Standorte VMware Live Site Recovery betreiben, ist eine geplante Migration damit ein weiterer Weg, beschrieben in unserem Artikel zu VMware Live Site Recovery; das Plattformmodell behandelt unser Vergleich von IaaS, Private Cloud und Hybrid.

Broadcom: Seiten zur Migration in vSphere 8.0 (16. September 2026), Cross-vCenter-Anforderungen in vSphere 8.0 (16. September 2026), KB 344959, HCX-Dokumentation zu VCF 9.1 (5. Oktober 2026); Veeam Backup & Replication 13 User Guide und Cloud Connect Guide. Die Spalte „Geeignet für“ ist unsere Lesart.

Cross vCenter vMotion und Advanced Cross vCenter vMotion

Cross vCenter vMotion verschiebt eine laufende VM auf einen Host unter einem anderen vCenter Server, „ohne jede Unterbrechung ihrer Verfügbarkeit“, die MAC-Adressen eingeschlossen. Broadcoms KB 344959 verlangt vCenter Server und ESXi 6.0 oder neuer auf beiden Seiten, zeitsynchronisierte vCenter und eine Enterprise-Plus-Lizenz für Cross vCenter vMotion und Long-Distance vMotion. Beide vCenter müssen außerdem im Enhanced Linked Mode verbunden sein, was eine gemeinsame Single-Sign-On-Domäne mit dem Provider bedeutet, es sei denn, die Migration läuft über die vSphere APIs oder das PowerCLI-Cmdlet Move-VM, die getrennte Domänen erlauben.

Advanced Cross vCenter vMotion (XVM), verfügbar ab vSphere 7.0 Update 1c, „hängt nicht von vCenter Enhanced Linked Mode oder Hybrid Linked Mode ab“ und importiert oder exportiert VMs über Single-Sign-On-Domänen hinweg. Laut Broadcoms Seite mit den Anforderungen in der Dokumentation zu vSphere 8.0 (16. September 2026) muss das vCenter, das den Vorgang startet, Version 7.0 Update 1c oder neuer haben, eingeschaltete VMs brauchen vSphere Enterprise Plus und ausgeschaltete nur vSphere Standard; Hosts mit vSphere Standard können XVM also als kalte Methode nutzen. Ab 7.0 Update 3 kann XVM eine VM auch klonen und das Original an Ort und Stelle lassen.

Beide Varianten brauchen geroutete Pfade, denen der Provider zustimmen muss. KB 344959 nennt TCP 8000 zwischen den vMotion-Adressen der ESXi-Hosts, TCP 902 zwischen ihren Adressen im Verwaltungsnetz für die Kopie der Festplatten und TCP 443 für die vCenter. Für große Entfernungen verlangt Broadcoms Dokumentation zu vSphere 8.0 eine Round-Trip-Time zwischen den Hosts von „bis zu 150 Millisekunden“, eine Lizenz, die Long-Distance vMotion abdeckt, und den Festplattenverkehr auf dem Provisioning-TCP/IP-Stack. Der vMotion-Verkehr wird verschlüsselt, wenn beide Hosts das unterstützen (Standard ist „Opportunistic“), und verschlüsselte VMs wechseln nur über die vSphere APIs zwischen vCenter-Instanzen, wobei beide vCenter den Key Provider, der sie verschlüsselt hat, unter demselben Namen gemeinsam nutzen.

Der Befehlssatz einer VM wird beim Einschalten festgelegt, und eine Live-Migration braucht einen Zielhost, der denselben Befehlssatz bereitstellt. Broadcom schreibt, dass Prozessoren „aus derselben Herstellerklasse (AMD oder Intel) stammen müssen, um vMotion-kompatibel zu sein“; ein Wechsel zwischen CPU-Herstellern braucht also eine kalte Methode oder eine mit Neustart.

Migration mit VMware HCX und Lizenzierung

HCX verschiebt VMs zwischen einem HCX Connector an der Quelle und einem HCX Cloud Manager am Ziel, sobald die Standorte gekoppelt sind und ein Service Mesh bereitgestellt ist. In VCF 9 heißt es VCF Operations HCX; Broadcoms FAQ zu VCF 9.1 vom 3. September 2026 führt HCX unter den Komponenten auf, die die VCF-Lizenzierung abdeckt, und vSphere Foundation enthält es nicht, wie unser Vergleich von VVF und VCF zeigt. Stand Oktober 2026 ergänzt KB 440126: „Eine lokale Lizenzierung ist am Quellstandort nicht erforderlich, wenn das Ziel eine lizenzierte VCF-Umgebung ist“; die Quelle erbt die Funktionen über das Service Mesh, kann aber „in den Evaluierungsstatus zurückfallen“, wenn ihre Verbindung zum Ziel länger als 10 Minuten unterbrochen ist.

Bulk Migration repliziert VMs parallel und hält bis zur geplanten Umschaltung eine Delta-Synchronisierung mit einem RPO von zwei Stunden aufrecht; bei der Umschaltung wird die Quell-VM für eine letzte Offline-Synchronisierung ausgeschaltet. Broadcom setzt die Unterbrechung einem Neustart gleich und nennt Network Extension „für Migrationen mit geringer Ausfallzeit erforderlich“. Bulk Migration setzt VMware Tools und Hardwareversion 7 oder neuer voraus, kann keine VMs mit RDMs im physischen Kompatibilitätsmodus oder mit virtuellen NVMe-Controllern verschieben und migriert keine Snapshots. HCX vMotion überträgt den laufenden Zustand ohne Unterbrechung, aber seriell je Service Mesh und mit mindestens 150 Mbit/s. Replication Assisted vMotion (RAV) repliziert die Festplatten vorab und schaltet per vMotion um, was parallele Wellen ohne Ausfallzeit ergibt, auch wenn gleichzeitige Umschaltungen weiterhin seriell je Service Mesh laufen; für RAV gilt dieselbe NVMe-Grenze, und RAV verschiebt überhaupt keine RDMs. Fragen Sie den Provider, welche Migrationstypen sein HCX Cloud Manager aktiviert hat, bevor Sie mit RAV planen.

Migration mit Veeam-Replikation und Planned Failover

Ohne HCX oder Pfade für vMotion übernimmt die Replikation das Kopieren vor dem Wartungsfenster. Ein Veeam-Replikationsjob erstellt im ersten Lauf ein vollständiges Replikat auf dem Zielhost, kopiert danach nur geänderte Blöcke, und das Replikat bleibt startbereit. Veeam beschreibt Planned Failover als manuelle Umschaltung auf das Replikat mit minimaler Unterbrechung und nennt die „Rechenzentrumsmigration“ als Einsatzzweck; sein Benutzerhandbuch für Version 13 nennt einen inkrementellen Lauf, das Herunterfahren der Quell-VM, einen zweiten Lauf mit den letzten Änderungen und den Start des Replikats, die Unterbrechung umfasst also das Herunterfahren, die letzten Änderungen und den Start. Veeam nennt den Failover „einen Zwischenschritt, der abgeschlossen werden muss“: Undo Failover kehrt zur ursprünglichen VM zurück und verwirft die Änderungen am Replikat, Failback überträgt sie auf das Original, und Permanent Failover macht das Replikat endgültig zur VM.

Eine Netzwerkzuordnungstabelle bildet Produktionsnetze auf Netze am Ziel ab, und Re-IP-Regeln ändern die Adressen der Replikate beim Failover, doch Veeams Assistent wendet sie nur auf eine Familie von Gastbetriebssystemen an; Linux-VMs brauchen also ein Skript. Bei einem Provider, der Veeam Cloud Connect betreibt, liegen die Replikate auf seinem Cloud-Host, wo Veeam weder Re-IP-Regeln noch DHCP unterstützt; die VMs behalten also ihre Adressen, die statisch sein müssen. Der Cloud Connect Guide erlaubt dort Permanent Failover „nach einem vollständigen Standort-Failover“, gestartet aus einem Cloud-Failover-Plan. Jobtypen und Replica Seeding behandelt unser Artikel zu Veeam-Replikation, Backup Copy und Cloud Connect, den Ablauf am Tag selbst unser Leitfaden zu den Schritten bei Failover und Failback.

OVF-Export und -Import

Der OVF-Export braucht keinen Pfad zwischen den Standorten, nur einen Weg, Dateien zu übertragen. Im vSphere Client schreibt „Export OVF Template“ eine ausgeschaltete VM als .ovf-, .vmdk- und .mf-Dateien; „In vSphere 6.5 und neuer können Sie keine OVA-Vorlagen exportieren“, und auch das VMware OVF Tool kann OVF-Vorlagen bereitstellen und exportieren. Verschlüsselte VMs lassen sich nicht exportieren. Die erweiterten Optionen fügen BIOS-UUID, MAC-Adressen, Bootreihenfolge und PCI-Slot-Nummern hinzu, die laut Broadcom „die Portabilität einschränken“; ohne sie erhält die importierte VM weder ihre ursprünglichen MAC-Adressen noch ihre BIOS-UUID. Die VM steht während des gesamten Ablaufs aus Export, Übertragung, Import und Prüfungen still, und bei dauerhaft 1 Gbit/s dauert die Übertragung von 1 TB exportierter Dateien mehr als zwei Stunden (unsere Rechnung).

Netzwerk: gestrecktes Layer-2-Netz oder Re-IP

Eine VM behält ihre IP-Adresse nur, wenn ihr Subnetz am Ziel existiert. Das leistet HCX Network Extension: Die Funktion erweitert VLAN-getaggte Portgruppen eines vSphere Distributed Switch sowie NSX-Segmente, und migrierte VMs behalten ihre IP- und MAC-Adressen und „verhalten sich, als befänden sie sich im selben L2-Netz“ wie die VMs, die noch an der Quelle laufen. Das Standard-Gateway bleibt an der Quelle, sodass Verkehr in andere Subnetze über die Verbindung zwischen den Standorten läuft. Ist die letzte VM eines Subnetzes umgezogen, heben Sie die Erweiterung des Netzes auf und verbinden das Zielsegment mit seinem Gateway, das HCX standardmäßig nicht anbindet, um einen Routing-Konflikt zu vermeiden; VMs, die an der Quelle DHCP oder statisch eingetragene DNS- oder NTP-Dienste nutzten, können diese Dienste verlieren. Ohne HCX zieht ein Subnetz mit seinem Gateway in einem einzigen Wartungsfenster um, oder Sie brauchen eine eigene Layer-2-Verbindung.

Bei Re-IP erhält jede VM am Ziel eine neue Adresse. Senken Sie die TTL jedes DNS-Eintrags, der sich ändern wird, spätestens so lange vor dem Wartungsfenster, wie die bisherige TTL beträgt, und erfassen Sie Firewall-Regeln, Allowlists von Partnern, fest eingetragene Adressen, Lizenzserver, Monitoring und Backup-Jobs. Bei Lizenzen, die an die Hardware-Identität gebunden sind, überträgt vMotion die MAC-Adressen mit dem Zustand der VM, HCX Bulk Migration behält sie, wenn „Retain MAC“ gewählt ist, und ein OVF-Export behält sie nur mit den erweiterten Optionen.

Hybrid ist bei unserer EU-Cloud ein Standardszenario: Ein Teil der Systeme bleibt bei Ihnen, ein Teil zieht in die Cloud, mit Replikation zwischen den Standorten. Schicken Sie uns Ihre VM-Liste mit den Subnetzen jeder VM und den Adressen, die sich nicht ändern dürfen.

Reihenfolge der Migration nach Abhängigkeiten

Ein Applikationsserver, der ohne seine Datenbank umzieht, schickt jede Abfrage über die Verbindung zwischen den Standorten; die Wellen folgen deshalb den Abhängigkeiten.

1. Erfassen Sie für jede VM den Verantwortlichen, die Festplattengröße, die Hardwareversion, die Festplatten-Controller, die Verschlüsselung, den CPU-Hersteller, den Status der VMware Tools, Snapshots, RDMs und Lizenzen, die an eine MAC-Adresse oder einen Host gebunden sind.
2. Ermitteln Sie die Abhängigkeiten aus Flow-Daten und Firewall-Logs und bestätigen Sie sie mit dem Verantwortlichen jeder Anwendung.
3. Bereiten Sie das Ziel vor: Netze oder Netzwerkerweiterungen, dort erreichbare Verzeichnis- und DNS-Dienste, Firewall-Regeln, Backup und Monitoring.
4. Führen Sie eine Pilotwelle mit unkritischen VMs durch, den Rückweg eingeschlossen.
5. Ziehen Sie jede Anwendung mit ihrer Datenbank und den Diensten, die sie häufig aufruft, in einem vereinbarten Wartungsfenster um, mit einem Test durch den Verantwortlichen und einem festen Zeitpunkt für die Go/No-go-Entscheidung.
6. Stellen Sie den externen Zugriff zuletzt um: öffentliches DNS, Zertifikate, NAT-Regeln und VPNs zu Partnern.
7. Lassen Sie alles, was an der Quelle verbleibt, bestehen, bis die Welle abgenommen ist.

Rückfallplan für jede Methode

Der Rückweg ist einfach, solange am Ziel keine Schreibvorgänge eingegangen sind, die erhalten bleiben müssen; danach müssen auch die neuen Daten zurück.

Broadcom TechDocs: HCX-Dokumentation zu VCF 9.1 (5. Oktober 2026), Benutzerhandbuch zu HCX 9.0 (25. Februar 2025), Dokumentation zur Migration in vSphere 8.0 (16. September 2026). Veeam Backup & Replication 13 Quick Start Guide (25. November 2025).

Die CPU-Funktionen einer VM werden beim Einschalten festgelegt; nach einem Aus- und Einschalten auf neueren Zielhosts kann ein vMotion zurück auf ältere Quellhosts deshalb scheitern, und mit einem EVC-Modus pro VM, der zu den Quellhosts passt, bleibt dieser Weg möglich. Weil „ein VMware-Produkt keine virtuelle Maschine einschalten kann, deren virtuelle Hardwareversion höher ist als die, die es unterstützt“, lassen Sie die HCX-Option „Upgrade Virtual Hardware“ ausgeschaltet, bis die Welle abgenommen ist.

Wir ziehen Systeme Schritt für Schritt um, in vereinbarten Wartungsfenstern, mit Rollback-Plan. Nennen Sie uns, welche Systeme Sie zuerst migrieren würden und wie Sie sie testen würden.

Was wir tun

Unser Service EU-Cloud hostet IaaS auf der VMware-vSphere-Plattform und dedizierte Private Clouds in Baltnetas Tier-3-Rechenzentren in Litauen (ISO 27001, PCI DSS); unser Engineering-Partner Vixen.UNO übernimmt Migrations-Engineering und Support. Das erste Gespräch ist kostenlos, und das kostenpflichtige technische Assessment, dessen Preis vor Beginn feststeht, prüft Ihre Systeme und die Zielkonfiguration und liefert einen Schritt-für-Schritt-Migrationsplan. Vor der Migration stellen wir einen Testzugang zur Plattform bereit und ziehen die Systeme dann in vereinbarten Wartungsfenstern um. Sie unterzeichnen einen Vertrag mit Eurokommerz und arbeiten mit einem Projektleiter.

FAQ