Migration von VMware in die Cloud: Plan, Methoden und Fallen

WebDisk Blog · Kategorie: Public Cloud · Lesezeit: ~10 Minuten

Kurz gefasst:- Nach der Übernahme von VMware durch Broadcom haben sich das Lizenzmodell und das Partnerprogramm geändert, sodass bei der Verlängerung des Supports immer mehr Unternehmen die Alternativen durchrechnen. Am häufigsten in Betracht gezogen wird KVM, verwaltet über Apache CloudStack – denn das Arbeitsmodell liegt nah an dem, was Administratoren aus vCenter kennen.- Zwei Wege: die Migration der Maschinen und Netzwerke in die WebDisk Public Cloud oder der Aufbau von CloudStack in der eigenen Umgebung, mit unserer Unterstützung. Beide Wege lassen sich etappenweise umsetzen, parallel zum laufenden vSphere.- Der technische Kern sind drei Methoden (OVA/OVF, Konvertierung der Festplatten nach qcow2, Synchronisation auf Systemebene), eine klassische Falle (virtio-Treiber) und eine Sache, die sich nicht überspringen lässt: der Rollback-Plan. >Sie arbeiten nicht mit dem Terminal? Überspringen Sie die Befehlsblöcke – Arbeitsreihenfolge, Fallen und Checkliste sind in Worten beschrieben.

Das Gespräch beginnt meist gleich: Die IT-Abteilung erhält ein Angebot zur Verlängerung des vSphere-Supports, schaut auf die Konditionen, schaut auf das Budget und stellt sich zum ersten Mal seit Jahren die Frage „Müssen wir das eigentlich?“. Nach der Übernahme von VMware durch Broadcom (die Transaktion wurde Ende 2023 abgeschlossen) haben sich mehrere Dinge auf einmal geändert: Das Portfolio wurde in große Pakete konsolidiert, unbefristete Lizenzen wichen Abonnements, und der Umbau des Partnerprogramms im Jahr 2024 veränderte die Liste der Unternehmen, die Lizenzen verkaufen und verlängern dürfen. Die finanziellen Folgen hängen vom konkreten Vertrag ab, nicht von einem Blogartikel – deshalb erhalten Sie hier statt Prozentzahlen einen Aktionsplan für den Fall, dass Ihre eigenen Berechnungen ungünstig ausfallen.

In diesem Artikel zeigen wir, was Sie in welcher Reihenfolge übertragen sollten, mit drei Methoden zur Übertragung einer Maschine, und wo Migrationen am häufigsten scheitern – mit einer Checkliste für eine einzelne Maschine und einem Rollback-Plan. Der Text richtet sich an IT-Teams vor der Verlängerung des vSphere-Supports: an die Administratoren, die es umsetzen werden, und an die Personen, die Risiko und Budget abschätzen müssen.

Zwei Wege: unsere Cloud oder CloudStack bei Ihnen

Weg eins – die Public Cloud. Sie übertragen Maschinen und Netzwerke in die WebDisk Public Cloud, müssen keinen eigenen Hypervisor mehr betreiben (Hypervisor – die Software, die virtuelle Maschinen auf einem physischen Server ausführt) und verwalten die Umgebung über das Panel von WebDisk Cloud. Den Kubernetes-Cluster bauen Sie in der neuen Umgebung neu auf – bei uns als Dienst WebDisk K8s – indem Sie Workloads und Volumes übertragen, nicht Maschinen. Abgerechnet wird monatlich, für den gebuchten Ressourcenpool, mit öffentlicher Preisliste in Złoty – der Kostenvergleich läuft also über Ihre Zahlen: die Summe aus vCPU, RAM, Kapazität und Transfer, gegenübergestellt den vollen Kosten des eigenen Serverraums, samt Energie, Hardware-Erneuerung und Arbeitszeit der Menschen.

Weg zwei – CloudStack im eigenen Serverraum. Sie bleiben auf Ihrer eigenen Hardware, nehmen ihr aber die Lizenzabhängigkeit: Apache CloudStack ist freie Software (Apache-2.0-Lizenz), entwickelt von der Apache Foundation. Unsere Rolle ist dann die Unterstützung, und deren Umfang – Konzeption, Implementierung, Übertragung der Maschinen, Schulung des Teams – vereinbaren wir individuell. Beide Wege lassen sich kombinieren – ein Teil der Umgebung bei Ihnen, ein Teil bei uns; wie beide Standorte verbunden werden, legen wir im Projekt fest.

Nennen wir das Kind beim Namen: Wenn Sie nicht bewusst eine offene Schicht wählen, tauschen Sie nur eine Abhängigkeit gegen eine andere – mehr dazu in unserem Text über Vendor Lock-in.

Warum ist CloudStack die natürliche Alternative zu vSphere?

Für den vSphere-Administrator ist CloudStack eine sanfte Landung – aus konkreten Gründen, nicht aus Sympathie:

Das Betriebsmodell ist vertraut. Die Hierarchie aus Zonen, Pods, Clustern und Hosts bildet ab, was in vCenter datacenter → cluster → host heißt, und die Arbeit findet in einem einzigen Web-Panel statt. CloudStack ist monolithisch und lässt sich daher einfacher einführen und betreiben als Plattformen, die aus über einem Dutzend Komponenten bestehen.
Ein Orchestrator, viele Hypervisoren. CloudStack verwaltet KVM, aber auch VMware vSphere oder XCP-ng. Das eröffnet die Umstiegsvariante mit dem geringsten Rückzugsrisiko: Sie starten CloudStack neben dem laufenden vSphere, binden den bestehenden Cluster als Ressource ein und migrieren die Maschinen schrittweise.
Vereinfachter Modus für On-Premises. Eine Zone lässt sich ohne Netzwerkvirtualisierung starten – die Instanzen landen direkt in einem gemeinsam genutzten Netz auf Ihren VLANs, was Unternehmen mit sauber geordneter Adressierung eine ganze Komplexitätsschicht erspart. Kubernetes-Cluster haben wiederum einen eigenen Plattformdienst: Die Control Plane richtet CloudStack ein, und Sie spielen Ihre Workloads und Daten hinein. Wenn Sie den Betrieb des Clusters lieber abgeben möchten, finden Sie bei uns technischen Support für Kubernetes.
Storage. Unsere Plattform basiert auf Ceph – als Blockspeicher für die Maschinen und als S3-kompatibler Object Storage. Kapazität kommt durch das Hinzufügen von Knoten dazu, ohne Stillstand der Maschinen.

Als ergänzende Lektüre empfiehlt sich der öffentliche Leitfaden „VMware to Apache CloudStack Migration Guide“ von ShapeBlue, einem stark in die Entwicklung von CloudStack eingebundenen Unternehmen.

Was zuerst übertragen und was zuletzt?

Der häufigste Fehler ist, mit der Maschine zu beginnen, die jemand am besten kennt – also mit der wichtigsten. Die Reihenfolge, die sich bewährt, ist die umgekehrte:

Inventarisierung. Export der Maschinenliste aus vCenter: vCPU, RAM, Festplatten und ihre tatsächliche Belegung, IP- und MAC-Adressen, Systemversion, Firmware (älteres BIOS oder neueres UEFI – der Modus, in dem die Maschine startet), Agents, an Hardware gebundene Lizenzen. Diese Tabelle ist die Grundlage des Zeitplans.
Abhängigkeitskarte. Was mit wem spricht und über welche Ports. Eine ohne ihre Datenbank übertragene Maschine ist keine Migration, sondern ein Ausfall mit Zeitzünder.
Das Fundament in der neuen Umgebung. Zuerst das Netzwerk (VPC, Subnetze, Regeln, NAT, Anbindung an Ihr Netz), dann DNS, Identität und Zugriff, Backup und Monitoring. Erst darauf setzt man die Maschinen auf.
Welle null – eine einzelne Nicht-Produktionsmaschine. Das Ziel ist prozedural: messen, wie lange Transfer und Konvertierung wirklich dauern, und den Rollback an etwas üben, um das es nicht schade ist.
Welle eins – zustandslose Dienste. Applikationsserver, Frontends, Hilfsmaschinen. Die Umschaltung (engl. cutover) ist günstig, weil keine Daten mit der Maschine migrieren.
Welle zwei – die Daten. Große Volumes sollten Sie früh „aussäen“ (Vollkopie im Voraus, im Wartungsfenster nur die Differenz), und die Archive verschieben Sie gleich in den Object Storage, statt sie in einer virtuellen Festplatte zu transportieren.
Letzte Welle – die kritischen Systeme, dann bereits nach eingeübter Prozedur.

Erstellen Sie vor der ersten Welle ein Backup außerhalb beider Umgebungen – die Migration ist der einzige Moment, in dem dieselben Daten an zwei Orten existieren und beide in Bewegung sind (von den Grundregeln erzählt der Text über das Backup in der Cloud, und von Speichern der WORM-Klasse – also solchen, in denen sich eine geschriebene Kopie vor Fristablauf weder überschreiben noch löschen lässt – der Text über S3 Object Lock).

Wie überträgt man eine virtuelle Maschine von VMware auf KVM? Drei Methoden

Methode A – OVA/OVF-Export (OVA und OVF sind Standardformate für den Export einer virtuellen Maschine in eine Datei). Der Klassiker: Die Maschine wird heruntergefahren, in eine einzige Datei exportiert und auf der anderen Seite importiert. Vorhersehbar, erfordert aber ein volles Wartungsfenster und Platz für zwei Kopien der Festplatte.

# Export der Maschine aus vSphere nach OVA (ovftool, von einem Host mit Zugriff auf vCenter)
ovftool --noSSLVerify \
vi://uzytkownik@vcenter.firma.local/Datacenter/vm/app-01 \
./app-01.ova

Methode B – Konvertierung der Festplatten. Das VMware-Format (VMDK) wandeln Sie in das für KVM native Format (QCOW2 oder RAW) um und registrieren es als Template oder Volume.

# Entpacken der OVA und Konvertierung der Festplatte VMDK -> QCOW2
tar -xvf app-01.ova # -> app-01.ovf, app-01-disk1.vmdk
qemu-img convert -p -f vmdk -O qcow2 app-01-disk1.vmdk app-01.qcow2
qemu-img info app-01.qcow2 # Kontrolle: Format und virtuelle Größe

Die sicherere Variante ist virt-v2v: Es konvertiert das Image und injiziert dabei die unter KVM benötigten Treiber in das Gastsystem – erledigt also die größte Falle aus dem nächsten Abschnitt. Eine Bedingung gibt es: Bei Windows-Maschinen müssen die virtio-win-Treiber auf der Maschine installiert sein, auf der Sie konvertieren. Ohne sie gelingt die Konvertierung, und das System startet trotzdem nicht.

# Konvertierung + Vorbereitung des Gastsystems für KVM in einem Schritt
virt-v2v -i ova app-01.ova -o local -os /var/tmp/wynik -of qcow2

Das fertige Image stellen Sie unter einer HTTP(S)-Adresse bereit und registrieren es in CloudStack als Template (Formular „Register template“ im Panel oder register template in cloudmonkey – Format QCOW2, Hypervisor KVM). Neuere Releases können eine Maschine auch direkt aus vCenter abholen und ohne manuelles Übertragen von Dateien nach KVM konvertieren; die Verfügbarkeit hängt von der Version ab, prüfen Sie das also in Ihrer Installation, bevor Sie den Zeitplan aufstellen.

Methode C – Synchronisation auf Systemebene. Statt die Festplatte zu transportieren, setzen Sie in der neuen Umgebung eine saubere Maschine auf, installieren die Software und übertragen die Daten. Sie schleppen dann keine alten Treiber, keine Überreste der VMware Tools und keine Update-Historie mit.

# erster Durchlauf — im laufenden Betrieb, die Quelle arbeitet weiter
rsync -aHAX --numeric-ids --info=progress2 root@stara-vm:/srv/ /srv/

# abschließender Durchlauf — im Wartungsfenster, nach dem Stoppen der Dienste;
# überträgt nur noch die Differenz, deshalb ist das Fenster kurz
rsync -aHAX --numeric-ids --delete root@stara-vm:/srv/ /srv/

In der Praxis: A für einfache, einzelne Maschinen; B für Appliances – fertige Maschinen vom Softwarehersteller, die sich nicht per Installer aufsetzen lassen; C für alles, was Sie neu aufbauen – und überall dort, wo ein kurzes Fenster zählt.

Fallen, die das Wartungsfenster auffressen

Virtio-Treiber. Die Nummer eins auf der Liste. Virtio ist die Treiberfamilie, über die eine virtuelle Maschine unter KVM mit Festplatte und Netzwerk spricht. Windows fährt ohne zuvor installierte virtio-Treiber nicht hoch (der klassische Stop-Fehler „inaccessible boot device“); Linux mit einem initramfs – einem kleinen Startsystem im Speicher, geladen bevor die eigentliche Festplatte bereitsteht –, das ohne virtio-Module gebaut wurde, bleibt an der fehlenden Festplatte hängen. Das Heilmittel ist einfach, sofern Sie es vor dem Herunterfahren der Quellmaschine anwenden: Installieren Sie die Treiber nach und bauen Sie das initramfs neu, oder verwenden Sie virt-v2v – unter der Bedingung, dass auf der Maschine, auf der Sie konvertieren, die virtio-win-Treiber installiert sind; ohne sie gelingt die Konvertierung, und Windows startet trotzdem nicht.
Namen der Netzwerkschnittstellen. Ein neuer Kartentyp bedeutet einen neuen Schnittstellennamen (ens192 wird mitunter zu ens3). Eine Konfiguration, die am alten Namen oder an der MAC-Adresse hängt, bedeutet eine Maschine, die ohne Netzwerk hochfährt. Prüfen Sie vor der Übertragung netplan, die Dateien ifcfg und die udev-Regeln.
MAC-Adressen, Lizenzen und Snapshots. Manche Software bindet die Lizenz an die MAC-Adresse, die UUID der Maschine oder die Seriennummer des Mainboards – erstellen Sie früh eine Liste solcher Systeme, denn die Umlizenzierung erledigt man vor der Migration, nicht im Wartungsfenster. Maschinen mit einer Snapshot-Kette migrieren Sie wiederum erst nach der Konsolidierung: Der Export mit aktiver Kette ist der kürzeste Weg zu einem Image, das nicht startet.
VMware Tools, UEFI und fstab. Deinstallieren Sie die VMware Tools vor der Migration, auf der anderen Seite installieren Sie qemu-guest-agent. Eine in UEFI startende Maschine muss auf einer UEFI-Instanz landen (die Unstimmigkeit zeigt sich als „schwarzer Bildschirm ohne Grund“), und fstab – die Datei mit der Liste der beim Systemstart eingebundenen Laufwerke –, beschrieben mit Gerätenamen statt UUID-Kennungen, ist ein sicherer Startausfall, sobald sich der Festplattencontroller ändert.
Transferzeit und DNS. Berechnen Sie die Kopierzeit im Voraus – Kapazität geteilt durch die reale Bandbreite der Leitung; einige Dutzend Terabyte sind keine Aufgabe für ein Wochenende. Und die TTL der DNS-Einträge – also die Zeit, die Server und Browser eine alte Antwort im Cache halten – senken Sie einen Tag vor der Umschaltung, sonst dauert die Umschaltung so lange wie der langlebigste Cache auf dem Weg – und der Rollback genau ebenso lange.

Test- und Rollback-Plan

Eine Migration ohne definierten Rollback ist keine Migration, sondern eine Wette. Das Minimum, das in die Prozedur gehört:

Abnahmekriterien (bevor der Traffic auf die neue Umgebung geht): Das System fährt nach zwei Neustarts hoch; die Konsole aus dem Panel funktioniert; Adressierung, Routen und DNS entsprechen dem Entwurf; der Dienst besteht einen End-to-End-Test (nicht „der Prozess läuft“, sondern „der Benutzer hat eine Operation ausgeführt“); die Festplattenleistung wurde mit dem Stand vor der Migration verglichen; das Backup wurde ausgeführt und probeweise wiederhergestellt; das Monitoring – Ihr eigenes oder ein mit uns vereinbartes – sieht die Maschine und alarmiert.

Rollback: Die Quellmaschine bleibt ausgeschaltet, aber unangetastet für die vereinbarte Zeit (ein vernünftiges Minimum sind zwei Wochen stabilen Betriebs). Definieren Sie den Point of no Return – den Moment, in dem in der neuen Umgebung Schreibvorgänge entstehen, die es in der alten nicht gibt: Bis zu diesem Moment ist der Rückzug kostenlos, danach erfordert er eine Rückmigration der Daten. Legen Sie außerdem fest, wer die Entscheidung verkündet, und eine harte Uhrzeit, zu der sie fällt („wenn wir um 4:00 keinen grünen Test haben, gehen wir zurück“) – um drei Uhr nachts will niemand derjenige sein, der als Erster den Rückzug vorschlägt.

Stellen Sie direkt nach der Umschaltung sicher, dass die Maschine von Ihrem Monitoring erfasst ist – und wenn ein eingefrorenes System von selbst neu starten soll, aktivieren Sie in ihr den Watchdog (die Reaktion ist ein harter Reset, keine Reparatur).

Checkliste für eine einzelne Maschine

T-14: Inventarisierung und Abhängigkeiten · Umlizenzierung dort, wo die Lizenz an der Hardware hängt · virtio-Treiber auf der Quelle nachinstalliert · Probe-Restore des Backups
T-2: Konsolidierung der Snapshots · Netzwerk von Schnittstellennamen und MAC-Adressen gelöst · erster Kopierdurchlauf „im laufenden Betrieb“ · Verifikation des Images nach der Konvertierung
T-1: gesenkte TTL im DNS · Wartungsfenster angekündigt · schriftliche Abnahmekriterien und Uhrzeit der Rollback-Entscheidung
T-0: Stoppen der Dienste · abschließender Datendurchlauf · Start der Zielmaschine · End-to-End-Test · Umschaltung des Traffics
T+1: Backup und Monitoring bestätigt · Quellmaschine ausgeschaltet, aber aufbewahrt · Dokumentation und Adressierung aktualisiert

Was löst eine Migration von VMware nicht?

Nicht jede Funktion hat eine Eins-zu-eins-Entsprechung. Automatischer Lastausgleich im Cluster oder die verteilte Firewall aus NSX haben in der KVM/CloudStack-Welt eigene, aber andere Lösungen. Statt nach einer Kopie zu suchen, prüfen Sie, welche dieser Funktionen bei Ihnen tatsächlich im Einsatz ist.
Kubernetes-Cluster werden neu aufgebaut. Migriert werden Manifeste, Images und die Daten auf den Volumes – nicht die Knoten. Planen Sie das als eigenes Projekt, nicht als eine der Wellen der Maschinenübertragung.
Der Hypervisor ist nicht die ganze Plattform. Backup, Monitoring und Identitätsmanagement müssen bewusst neu aufgebaut werden – das ist meist ein größerer Teil des Projekts als die reine Übertragung der Festplatten.
Die Migration kostet einmalig: Arbeitszeit der Menschen, Wartungsfenster, Risiko. Stellen Sie diese Kosten neben die Lizenzeinsparungen, bevor es das Business für Sie tut.
Wer auf eigener Hardware bleibt, bleibt Cloud-Betreiber. Freie Software nimmt Ihnen die Lizenzgebühr ab, nicht die Pflichten: Updates, Festplattentausch, Kapazität, Bereitschaftsdienste.

Häufige Fragen

Muss ich alles auf einmal migrieren? Nein – und es ist besser, wenn Sie es nicht tun. CloudStack verwaltet KVM und vSphere gleichzeitig, sodass beide Umgebungen während der gesamten Übergangszeit parallel laufen können und die Umschaltung in Wellen erfolgt.

Lassen sich Windows-Maschinen übertragen? Ja, unter der Voraussetzung, dass die virtio-Treiber vorab auf der Quelle vorbereitet wurden – oder mit virt-v2v, das dies während der Konvertierung erledigt, sofern auf der konvertierenden Maschine die virtio-win-Treiber installiert sind (ohne sie gelingt die Konvertierung, und Windows startet trotzdem nicht). Die Lizenzen von System und Anwendungen prüfen Sie separat – sie sind mitunter an die Hardware gebunden.

Worin unterscheiden sich die drei Methoden zur Übertragung einer Maschine: OVA/OVF, Festplattenkonvertierung und Datensynchronisation? Der OVA/OVF-Export überträgt die ganze Maschine in einer einzigen Datei – er ist vorhersehbar, erfordert aber ein volles Wartungsfenster und Platz für zwei Kopien der Festplatte. Die Konvertierung der Festplatten (VMDK nach QCOW2, am besten mit dem Werkzeug virt-v2v, das dabei auch gleich die Treiber injiziert) bewährt sich bei Appliances, die sich nicht per Installer aufsetzen lassen. Die Synchronisation auf Systemebene – eine saubere Maschine in der neuen Umgebung plus die Übertragung nur der Daten – ergibt das kürzeste Fenster und schleppt keine VMware-Überreste mit.

Warum startet Windows oder Linux nach der Migration von VMware auf KVM nicht? Der häufigste Grund sind fehlende virtio-Treiber: Windows endet mit dem Stop-Fehler „inaccessible boot device“, und Linux mit einem ohne virtio-Module gebauten initramfs bleibt an der fehlenden Festplatte hängen. Die zwei übrigen Verdächtigen sind ein nicht passender Startmodus (eine UEFI-Maschine als BIOS gestartet) und ein fstab mit Gerätenamen statt UUID-Kennungen. Das Heilmittel wendet man vor dem Herunterfahren der Quellmaschine an: Nachinstallieren der Treiber und Neubau des initramfs oder Konvertierung mit virt-v2v.

Bleiben meine Daten in Europa? Ja. Die Infrastruktur, auf der wir unsere Dienste erbringen, befindet sich auf dem Gebiet Polens – das erklärt unsere Datenschutzerklärung; dasselbe Dokument beschreibt die Ausnahmen (Analyse- und Abrechnungsdaten, verarbeitet von Anbietern außerhalb des EWR auf Basis von Standardvertragsklauseln). Den Auftragsverarbeitungsvertrag (DPA) samt Liste der Unterauftragnehmer stellen wir Kunden auf Wunsch bereit. Warum das für einen Teil der Organisationen das entscheidende Argument ist, beschreiben wir im Text über die polnische Cloud.

Wir möchten auf eigener Infrastruktur bleiben. Helfen Sie uns? Ja – den Umfang (Konzeption, Implementierung von CloudStack auf Ihrer Hardware, Übertragung der Maschinen, Schulung des Teams) vereinbaren wir individuell. CloudStack ist freie Software, nach Projektabschluss bleibt die Umgebung also Ihre.

Fazit

Die Migration von VMware ist technisch nicht schwierig – sie ist organisatorisch schwierig. Die Konvertierung einer Festplatte sind ein paar Befehle; ob die Umschaltung um zwei Uhr nachts oder um sechs Uhr morgens endet, entscheiden der Zeitplan der Wellen, die Abhängigkeitskarte, vorab vorbereitete Treiber und der vereinbarte Moment des Rückzugs. Und wenn die Rechnung noch offen ist und Sie neben CloudStack auch die Hyperscaler durchrechnen, hilft Ihnen der Vergleich Hyperscaler oder polnische Cloud.

Der günstigste erste Schritt ist ein Gespräch und ein Test an einer einzelnen Maschine: Wir gehen Ihre Inventartabelle durch, zeigen, wie die Arbeit im Panel aussieht, und sagen offen, was sich reibungslos übertragen lässt und was Arbeit erfordern wird. Schreiben Sie uns oder werfen Sie einen Blick auf die WebDisk Public Cloud.

Migration von VMware zu WebDisk Cloud: Was Sie übertragen, in welcher Reihenfolge und womit