VMware-Exit: Migrationsstrategien von der Bestandsaufnahme bis zum Rückweg

Die schwierigste VM in einem VMware-Ausstieg ist selten die größte. Meist ist es ein Windows Server mit drei Netzwerkkarten, fest eingetragenen Adressen und einer Fachanwendung, deren Lizenz an der MAC-Adresse hängt. Die Datenbank mit mehreren Terabyte daneben macht weniger Ärger, weil jeder weiß, dass sie Aufmerksamkeit braucht.

Wie groß solche Projekte werden können, zeigt eine Schätzung von Gartner, über die heise berichtet hat: bis zu 3.000 US-Dollar pro VM und 18 bis 48 Monate für eine vollständige Migration. Die Rechnung unterstellt mehr als 2.000 VMs auf über 100 Servern und einen externen Dienstleister. Neue Hardware und Anwendungstests sind darin nicht enthalten. Für Ihre Umgebung stimmen diese Zahlen wahrscheinlich nicht. Sie zeigen aber, wohin der Aufwand fließt. Das Kopieren der Platten ist der kleinste Posten, Planung, Abstimmung mit den Fachbereichen und Tests sind die großen.

Dieser Artikel beschreibt die Entscheidungen, die vor der ersten migrierten VM fallen sollten. Die meisten gelten unabhängig vom Werkzeug. Wo unser Migrationswerkzeug FCS Beam etwas davon übernimmt, steht es dabei, ebenso wie das, was es nicht übernimmt.

Bestandsaufnahme: Was vCenter nicht weiß

Ein Export aus vCenter, etwa mit RVTools, liefert ungefähr die Hälfte dessen, was Sie brauchen: Name, CPU, RAM, Platten, Netzwerkkarten, Snapshots, eingestelltes Betriebssystem. Die andere Hälfte steht in keinem System. Wem gehört die VM, wer prüft sie nach dem Umzug, wann darf sie aus sein, und mit welchen anderen Systemen spricht sie?

Technisch lohnt es sich, je VM mehr zu erfassen, als die Exportliste hergibt. Jeder der folgenden Punkte erzwingt später eine Entscheidung:

• Firmware: BIOS oder UEFI, Secure Boot, virtuelles TPM. Eine VM mit vTPM oder Verschlüsselung braucht am Ziel eine Entsprechung und beim Auslesen in vCenter zusätzliche Rechte.
• Platten: Anzahl, Größe, Controller. Platten im Modus „independent“ erfasst kein Snapshot. Raw Device Mappings und gemeinsam genutzte Platten für Gast-Cluster sind Sonderfälle, für die Sie meist eine eigene Lösung brauchen.
• Netz: Anzahl der Karten, VLANs, feste Adressen oder DHCP, DHCP-Reservierungen nach MAC-Adresse.
• Änderungsrate: Wie viele Daten ändern sich pro Tag? Davon hängt ab, ob sich ein Abgleich vor dem Umschalten lohnt. Ist Changed Block Tracking (CBT) aktiv?
• Altlasten: vergessene Snapshots, eingehängte ISO-Dateien, durchgereichte USB-Geräte oder Lizenz-Dongles.
• Lizenzen im Gast: Bindung an MAC-Adresse, Hardware-ID oder Anzahl der CPU-Sockel.

Ein Punkt wird fast immer übersehen. Das Betriebssystem, das in den VM-Einstellungen steht, ist zunächst nur eine Einstellung. Hinter „Other Linux (64-bit)“ kann ein aktuelles Ubuntu stecken oder ein CentOS, das seit Jahren keine Updates mehr bekommt. Was wirklich installiert ist, verrät erst ein Blick ins System.

Wir würden für jede VM eine fachlich verantwortliche Person eintragen, bevor sie in eine Welle kommt. Findet sich niemand, ist die VM entweder überflüssig oder ein Risiko, und beides sollten Sie vor dem Umzug wissen. Fast jede Bestandsaufnahme fördert Maschinen zutage, die niemand mehr braucht. Die günstigste Migration ist die, die nicht stattfindet.

Wellen nach Anwendungen schneiden

Die naheliegende Einteilung ist technisch: erst Cluster A, dann Datastore B. Wir halten das für einen Fehler. Läuft der Webserver einer Anwendung schon am Ziel, während ihre Datenbank noch in vSphere steht, liegt für die Dauer der Welle eine zusätzliche Netzstrecke dazwischen, oft mit Firewall oder Standortverbindung. Das erzeugt Fehler, die es vorher nicht gab und hinterher nicht mehr gibt. Reproduzieren kann sie dann niemand.

Schneiden Sie die Wellen deshalb nach Anwendungen und ihren Abhängigkeiten. Eine Reihenfolge, die sich gut planen lässt:

1. Pilot mit absichtlich schwierigen VMs (dazu gleich mehr).
2. Unkritische Anwendungen mit wenigen Abhängigkeiten. Hier schärfen Sie Ablauf und Runbook.
3. Die breite Masse der Standardfälle, in größeren Wellen.
4. Kritische und ungewöhnliche Systeme zuletzt, wenn das Team den Ablauf beherrscht.

Zwei Regeln würden wir nicht verhandeln. Während einer Welle baut niemand an den betroffenen VMs. Und eine Welle ist abgeschlossen, wenn der Fachbereich abgenommen hat, nicht schon dann, wenn die letzte VM läuft.

Der Pilot soll Probleme finden

Ein Pilot mit drei frisch installierten Test-VMs beweist, dass ein Werkzeug grundsätzlich funktioniert. Über Ihre Umgebung sagt er nichts. Nehmen Sie echte VMs, auf die Sie im Zweifel eine Weile verzichten können, und decken Sie die unangenehmen Fälle ab: jede Betriebssystemfamilie, die Sie betreiben, einen Windows Server mit mehreren Netzwerkkarten und festen Adressen, je eine VM mit BIOS und mit UEFI, ein System mit hoher Änderungsrate und ein Domänenmitglied.

Messen Sie im Pilot alles, was später den Zeitplan bestimmt: Dauer der Erstkopie, Dauer eines Abgleichs, Zeit vom Herunterfahren bis zur Abnahme durch den Fachbereich. Diese Werte hängen an Ihrem Speicher, Ihrem Netz und Ihrer Zielplattform. Eine Herstellerangabe ersetzt sie nicht, unsere auch nicht.

Aus dem Pilot entsteht das Runbook. Es beantwortet für jede Welle, wer was herunterfährt, wer was prüft, wer über den Rückweg entscheidet und bis wann er noch genommen werden darf.

Warm oder kalt umziehen

Bei der Kalt-Migration fahren Sie die VM herunter, kopieren alle Platten und starten am Ziel. Das Verfahren hat die wenigsten beweglichen Teile, und der Datenstand ist eindeutig. Dafür bleibt die VM so lange aus, wie das Kopieren der gesamten Datenmenge dauert, dazu kommen Anpassung, Start und Test. Für kleine VMs, für Systeme mit großzügigem Wartungsfenster und für alles, was nachts ohnehin niemand nutzt, ist das oft die vernünftige Wahl.

Bei der warmen Migration kopieren Sie zuerst bei laufender Quelle und gleichen danach die geänderten Blöcke ab, so oft Sie wollen. Erst zum Umschalten wird die Quelle heruntergefahren, ein letzter Abgleich überträgt den Rest. Die Ausfallzeit hängt dann nicht mehr an der gesamten Datenmenge, sondern an den Änderungen seit dem letzten Abgleich, plus Anpassung, Start und Test.

Das warme Verfahren hat Voraussetzungen und Nebenwirkungen:

• Abgleiche setzen Snapshots und CBT voraus. Snapshots auf laufenden VMs belegen Platz auf dem Datastore und verursachen beim Anlegen und Entfernen Last. Planen Sie freien Platz ein und beobachten Sie VMs mit vielen Schreibzugriffen.
• Für einen Snapshot mit konsistentem Gastdateisystem müssen die VMware Tools im Gast laufen.
• Viele Werkzeuge lesen die Platten über das Virtual Disk Development Kit (VDDK) von VMware. Laut heise hat Broadcom die öffentlichen Downloads um den 25. August 2026 entfernt, Zugang gibt es seitdem nur über ausgewählte Partner. Klären Sie früh, ob Ihr Werkzeug VDDK zwingend braucht und woher Sie es beziehen.

Wir würden warm migrieren, wo das Wartungsfenster der Engpass ist, und kalt, wo es keiner ist. Ein mehrstufiges Verfahren für eine kleine VM, die am Wochenende niemand nutzt, ist Aufwand ohne Gegenwert.

Quelle abschalten oder weiterlaufen lassen

Im Normalfall wird die Quelle heruntergefahren und bleibt aus. Zwei laufende Kopien derselben Maschine erzeugen Probleme, die nicht sofort auffallen:

• doppelte IP- und MAC-Adressen im Netz,
• ein Windows-Computerkonto, dessen Kennwort eine der beiden Kopien turnusgemäß ändert, worauf die andere die Vertrauensstellung zur Domäne verliert,
• Cronjobs und geplante Tasks, die doppelt laufen und zum Beispiel Rechnungen zweimal verschicken,
• Schreibzugriffe, die sich auf zwei Datenbestände verteilen und sich hinterher kaum zusammenführen lassen.

Bei Domänencontrollern gibt es keinen Spielraum. Ein migrierter Domänencontroller darf an der Quelle nicht wieder starten, sonst laufen zwei Fassungen desselben Verzeichnisses auseinander.

Weiterlaufen lassen ist sinnvoll, wenn Sie das Ziel vor dem eigentlichen Umzug ausprobieren wollen, etwa für einen Lasttest oder eine Abnahme mit Testdaten. Dann gehört die Kopie in ein getrenntes Netz, mit eigener IP-Adresse und eigener MAC-Adresse. Wir halten Parallelbetrieb für ein Testwerkzeug. Für den Umzug selbst würden wir ihn nicht einsetzen.

Netz und IP-Adressen

Adressen behalten ist für die Anwendungen am bequemsten, niemand muss Konfigurationen anfassen. Es setzt aber voraus, dass das Ziel im selben Layer-2-Segment hängt oder dass Sie ein ganzes Subnetz auf einmal umziehen und das Routing umstellen. Im zweiten Fall müssen alle VMs dieses Subnetzes in dieselbe Welle, was Ihre Planung nach Anwendungen durchkreuzen kann.

Eine vorübergehend über beide Umgebungen gespannte Layer-2-Verbindung löst das. Als Brücke für die Migration halten wir das für vertretbar. Als Dauerzustand würden wir es nicht betreiben, weil eine Schleife oder ein Broadcast-Sturm dann beide Seiten trifft. Geben Sie jeder solchen Brücke ein Abbaudatum, bevor Sie sie aufbauen.

Adressen ändern ist sauberer und in der Vorbereitung teurer. DNS-TTLs müssen rechtzeitig sinken, und fest eingetragene IP-Adressen stecken in Konfigurationsdateien, Skripten, Firewall-Regeln, Lizenzdateien und manchmal in der Datenbank der Anwendung. Finden lassen sie sich nur durch Suchen: Konfigurationsverzeichnisse durchsuchen, Firewall-Regeln exportieren, DNS-Logs auswerten.

MAC-Adressen bleiben je nach Werkzeug und Zielplattform erhalten oder nicht. Neue MAC-Adressen treffen DHCP-Reservierungen, Port-Security auf Switches und Lizenzen mit MAC-Bindung.

Dann der Gast selbst. Linux benennt Netzwerkschnittstellen nach Treiber und Steckplatz. Aus ens192 wird am Ziel zum Beispiel enp1s0, und eine Konfiguration, die auf den alten Namen zeigt, greift ins Leere. Windows behält die Einstellungen der alten VMXNET3-Karte als ausgeblendetes Gerät. Wer der neuen Karte die alte Adresse geben will, bekommt die Meldung, sie sei bereits einem anderen Adapter zugewiesen.

Treiber und Gastanpassung

Für das Gastbetriebssystem ändert sich beim Wechsel die gesamte virtuelle Hardware. Aus dem VMware-Paravirtual-Controller wird ein VirtIO- oder Hyper-V-Controller, aus der VMXNET3-Karte eine VirtIO- oder Hyper-V-Netzwerkkarte. Damit das System überhaupt bootet, muss der neue Speichertreiber vor dem ersten Start bereitstehen. Bei Linux heißt das, er muss in der initramfs stecken. Bei Windows muss er installiert und als Starttreiber eingetragen sein, sonst endet der erste Start mit INACCESSIBLE_BOOT_DEVICE.

Danach kommt der Rest: VMware Tools entfernen, den Gastagenten der neuen Plattform installieren (bei KVM-basierten Plattformen in der Regel den QEMU Guest Agent), den Zeitabgleich prüfen, Bootloader und /etc/fstab auf Gerätenamen prüfen, die sich geändert haben können. Rechnen Sie außerdem damit, dass Windows und manche Fachsoftware nach dem Umzug neu aktiviert werden wollen, weil sich aus ihrer Sicht die Hardware geändert hat.

Für zehn VMs lässt sich das von Hand erledigen, mit Checkliste und Geduld. Für dreihundert nicht.

Was FCS Beam davon übernimmt

An dieser Stelle setzt FCS Beam an. FCS Beam migriert von VMware vSphere auf SUSE Virtualization, OpenStack, Proxmox VE, Microsoft Hyper-V und KVM/libvirt. FCS Beam spricht mit vCenter und liest die Platten, in den Quell-VMs wird nichts installiert. Für Snapshots mit konsistentem Gastdateisystem nutzt FCS Beam die VMware Tools, die dort ohnehin laufen. Die Daten fließen direkt von der Quelle in die Ziel-Volumes. Mit unserem Portal spricht die FCS-Beam-Appliance für Aktivierung und Ausführungspläne. Dabei gehen Konfigurationsdaten über die Leitung, keine Inhalte Ihrer Maschinen.

Der Ablauf entspricht dem warmen Verfahren: Erstkopie bei laufender Quelle, danach Abgleiche der geänderten Blöcke per CBT. Zum Umschalten fährt FCS Beam die Quelle im üblichen Fall sauber herunter, gleicht ein letztes Mal ab, passt das Gastsystem an und startet die VM am Ziel. Bei Linux und Windows Server tauscht FCS Beam dabei die Treiber, richtet den Bootloader neu ein, zieht die Netzwerkkonfiguration nach und entfernt die VMware-Treiber. Fehlt der Nachweis, dass jede Platte vollständig übertragen wurde, setzt FCS Beam die Migration nicht fort.

Ob die Quelle heruntergefahren wird, entscheiden Sie beim Migrieren ausdrücklich. Soll sie weiterlaufen, legen Sie vorher feste Zieladressen je Netzwerkkarte, neue MAC-Adressen und ein von der Quelle getrenntes Zielnetz fest und bestätigen die angezeigten Auswirkungen.

VDDK ist für FCS Beam optional. Wenn Sie es nutzen wollen, bringen Sie es unter Ihrem eigenen Broadcom-Nutzungsrecht mit. Ohne VDDK liest FCS Beam die Platten über einen eigenen NFC-Leseweg oder auch per Hot-Add, einschließlich der per CBT erkannten Änderungen. Auch verschlüsselte Disks und VMs können migriert werden. Platten im Modus „independent“ unterstützt dieser Leseweg nicht.

Was FCS Beam nicht übernimmt: die Klärung von Zuständigkeiten und Abhängigkeiten, die Wellenplanung, die Abnahme durch den Fachbereich und Ihre Datensicherung. FCS Beam ist kein Ersatz für eine Backup-Lösung. Für Windows bereiten Sie je Zielplattform einmal eine Vorlage für die Arbeits-VM vor, die den Umbau erledigt. Und bei Windows mit mehreren Netzwerkkarten bleibt Handarbeit: Windows kann die feste Konfiguration der Quelle nicht zuverlässig einer bestimmten Karte zuordnen. Dort geben Sie je Karte neue Adressen vor oder nutzen DHCP.

Tests, die etwas beweisen

„Die VM startet und antwortet auf Ping“ ist kein Test. Auf Systemebene prüfen Sie mindestens den Start ohne Fehlermeldung, alle Platten und Dateisysteme, die richtige Adresse auf der richtigen Karte, die Uhrzeit, die Dienste und ob sich der Gastagent meldet.

Danach kommt der Teil, den nur der Fachbereich leisten kann: ein echter fachlicher Ablauf. Eine Buchung, eine Anmeldung mit einem normalen Benutzerkonto, ein Bericht, der Daten aus einem anderen System zieht. Legen Sie diese Prüfungen vor der Welle fest und schreiben Sie auf, wer sie ausführt. Sonst testet am Umschalttag jeder irgendetwas, und niemand das Richtige.

Am häufigsten fehlt der Betrieb, weil er am Umschalttag nicht auffällt. Hat die Datensicherung auf dem Ziel schon einmal erfolgreich gesichert, und lässt sich daraus etwas zurückholen? Sieht das Monitoring die VM, kommen ihre Logs an? Wenn nicht, merken Sie es Wochen später, wenn jemand eine gelöschte Datei zurückhaben will.

Der Rückweg

Ein Rückweg, der erst im Ernstfall geplant wird, ist keiner. Legen Sie vor jeder Welle fest, woran Sie erkennen, dass etwas schiefgeht, wer dann entscheidet und bis wann der Rückweg überhaupt noch sinnvoll ist.

Die letzte Frage ist die wichtigste. Solange auf dem Ziel nichts Wichtiges geschrieben wurde, heißt Rückweg: Ziel-VM aus, Quell-VM an. Sobald Anwender auf dem Ziel arbeiten, verlieren Sie mit dem Rückweg deren Änderungen, oder Sie müssen sie von Hand zurückholen. Irgendwann ist der Rückweg teurer als jedes Problem auf dem Ziel. Diesen Zeitpunkt sollten Sie kennen, bevor Sie umschalten.

Technisch braucht der Rückweg vor allem eines: eine unveränderte, ausgeschaltete Quell-VM. Löschen Sie sie nicht, verschieben Sie sie nicht, und sorgen Sie dafür, dass niemand „aufräumt“. Wir würden keine Quell-VM löschen, bevor auf dem Ziel eine Datensicherung gelaufen ist, eine Rücksicherung daraus geklappt hat und ein Monatsabschluss oder ein vergleichbarer Geschäftszyklus durch ist. Danach allerdings konsequent, sonst bezahlen Sie Speicher und Lizenzen doppelt.

Für FCS Beam heißt das konkret: FCS Beam repliziert nicht von der Zielplattform zurück nach vSphere. Eine Rücknahme in FCS Beam ist keine Rücksynchronisierung, Änderungen an der Ziel-VM wandern nicht zur Quelle zurück. Eine heruntergefahrene Quelle schaltet FCS Beam nicht von selbst wieder ein. Ihr Rückweg ist also genau diese ausgeschaltete Quell-VM, und deshalb steht sie bis zum Ende der Frist unter Schutz.

Woran Migrationen typischerweise scheitern

• Wellen nach Infrastruktur geschnitten. Die Hälfte einer Anwendung läuft am Ziel, die andere in der Quelle, dazwischen eine Strecke, die nie jemand getestet hat.
• Pilot mit Test-VMs. Er beweist das Werkzeug, nicht den Ablauf in Ihrer Umgebung.
• Lizenzen vergessen. MAC-Bindung, Dongles, Windows-Aktivierung, Software, die Hardware-IDs prüft.
• Datensicherung und Monitoring erst hinterher. Die ersten VMs laufen am Ziel ohne Sicherung, und es fällt erst auf, wenn sie gebraucht wird.
• Zeitplan aus Datenblättern. Dauer und Durchsatz ergeben sich aus Ihrem Pilot, nirgendwo sonst.
• Migrationswerkzeug mit Backup verwechselt. Ein Werkzeug, das kopiert, ist noch keine Sicherung mit Aufbewahrung und geprüfter Rücksicherung.
• Quell-VMs zu früh gelöscht. Oder nie. Das eine kostet den Rückweg, das andere Speicher und Lizenzen.

---

Den Ablauf an eigenen VMs ausprobieren. Auf der FCS-Beam-Seite finden Sie Ablauf, Voraussetzungen und Zielplattformen. FCS Beam lässt sich 14 Tage kostenlos mit bis zu 10 VMs testen, genug für einen Pilot nach dem Muster oben. Wenn noch offen ist, wohin Ihre VMs gehen sollen, lesen Sie unseren Vergleich der Plattformen nach VMware.