Planung Ihrer Migration von VMware zu KubeVirt

Die Übernahme von VMware durch Broadcom hat die wirtschaftlichen Rahmenbedingungen der Unternehmensvirtualisierung über Nacht verändert. Für viele Unternehmen haben sich die Lizenzkosten verdoppelt oder verdreifacht, und das Modell der unbefristeten Lizenzen, auf das sich Teams zur Sicherstellung der Budgetplanbarkeit verlassen haben, gibt es nicht mehr. Wenn Sie dies lesen, spüren Sie diesen Druck wahrscheinlich gerade selbst.

KubeVirt entwickelt sich zur führenden Open-Source-Alternative. Damit können Sie virtuelle Maschinen auf Kubernetes ohne Lizenzgebühren ausführen, wobei Sie Standardhardware und dieselbe Orchestrierungsschicht nutzen, die Sie bereits für Container verwenden. Das Projekt ist ausgereift, wird von Red Hat und der CNCF unterstützt (derzeit ein Incubating-Projekt) und wird von Unternehmen aus verschiedenen Branchen im Produktivbetrieb eingesetzt.

Doch Migration ist nicht einfach nur eine Frage des „Lift-and-Shift“. VMware und Kubernetes weisen grundlegend unterschiedliche Architekturen, unterschiedliche Netzwerkmodelle, unterschiedliche storage und unterschiedliche Betriebsabläufe auf. Eine überstürzte Migration ohne Plan ist der schnellste Weg zu einem gescheiterten Projekt und einem frustrierten Team.

Dieser Leitfaden führt Sie durch die Planungsphase: Bestandsaufnahme Ihrer VMware-Umgebung, Abgleich der Konzepte zwischen den Plattformen, Auswahl eines Migrationspfads, Entwurf Ihrer Zielarchitektur und Erstellung eines stufenweisen Runbooks, das das Risiko in jedem Schritt minimiert. Am Ende verfügen Sie über einen klaren Plan, den Sie Ihrem Team und Ihrer Führungsebene vorlegen können.

Dies ist der Planungsleitfaden. Das praktische Tutorial zur Konvertierung, in dem Sie mit „virt-v2v“ VMware-VMs in KubeVirt konvertieren, wird in Teil 2 dieser Reihe behandelt.

Schritt 1: Bestandsaufnahme Ihrer aktuellen VMware-Umgebung

Bevor Sie mit der Migration beginnen, benötigen Sie eine klare Bestandsaufnahme. Das klingt selbstverständlich, doch die meisten Unternehmen unterschätzen, wie viel institutionelles Wissen in ihrem vCenter verborgen ist. Im Laufe der Jahre sammeln sich immer mehr VMs an, und die Dokumentation gerät zunehmend aus dem Ruder. Beginnen Sie damit, jede VM zu dokumentieren, die Sie migrieren möchten.

Erfassen Sie für jede VM folgende Angaben:

Nutzen Sie die Exportfunktion von vCenter oder Tools wie RVTools, um dieses Inventar automatisch zu erstellen. RVTools ist besonders nützlich, da es Daten in Tabellenkalkulationen exportiert, was das Sortieren, Filtern und Teilen mit Ihrem Team erleichtert.

Ermitteln Sie beim Erstellen dieser Bestandsaufnahme, welche VMs eher für eine Containerisierung als für eine Migration in Frage kommen. Wenn eine Workload bereits zustandslos ist, einen einzigen Anwendungsprozess ausführt und keine Abhängigkeit vom zugrunde liegenden Betriebssystem aufweist, sollte sie wahrscheinlich gar keine VM sein. Diese Workloads sollten den Schritt über die VM komplett überspringen und direkt auf Container umgestellt werden. Ihr Migrationsprojekt bietet eine gute Gelegenheit, diese Entscheidung zu treffen.

Schritt 2: Zuordnung von VMware-Konzepten zu KubeVirt

Dies ist der Umdenkprozess, den Ihr Team verinnerlichen muss, bevor es sich mit den Tools befasst. VMware und KubeVirt lösen dasselbe Problem – nämlich das Ausführen virtueller Maschinen –, nutzen dabei jedoch völlig unterschiedliche Abstraktionsmodelle. Wenn Ihr Team versucht, KubeVirt so zu bedienen wie vCenter, wird es Schwierigkeiten haben.

Hier ist die Zuordnung:

Die wichtigste Veränderung betrifft den Betrieb. Bei VMware verwalten Sie die Infrastruktur über eine grafische Benutzeroberfläche (vCenter) mit Point-and-Click-Workflows. Bei KubeVirt erfolgt alles über ein YAML-Manifest, das über kubectl oder virtctl angewendet wird. Ihre Infrastruktur wird zu Code, was einen erheblichen Vorteil für die Automatisierung und Reproduzierbarkeit darstellt, jedoch andere Kenntnisse erfordert.

Nehmen Sie sich gemeinsam mit Ihrem Team Zeit, diese Zuordnung durchzugehen. Stellen Sie sicher, dass jeder versteht, wo die ihm vertrauten VMware-Konzepte in der Kubernetes-Welt angesiedelt sind, bevor Sie mit der Migration von Workloads beginnen.

Schritt 3: Wählen Sie Ihren Migrationspfad

Es gibt drei Ansätze, und die meisten Organisationen greifen letztendlich auf eine Kombination aus allen dreien zurück.

Pfad A: Forklift (Migrations-Toolkit für Virtualisierung)

Forklift ist ein Open-Source-Tool (Teil des Konveyor-Community-Projekts und die Upstream-Version des Red Hat Migration Toolkit for Virtualization), das die Massenmigration von VMs von VMware zu KubeVirt automatisiert. Es stellt eine direkte Verbindung zu Ihrem vCenter her, erkennt VMs, konvertiert Festplatten-Images und importiert diese in Ihren Kubernetes-Cluster.

Dies ist die richtige Wahl für große Umgebungen mit 50 oder mehr VMs, in denen eine manuelle Konvertierung zu lange dauern würde. Forklift übernimmt die sich wiederholenden Aufgaben: Festplattenkonvertierung, Netzwerkzuordnung und Erstellung von VMs. Außerdem bietet es eine Weboberfläche zur Verfolgung des Migrationsfortschritts, was für die Berichterstattung an die Beteiligten nützlich ist.

Der Nachteil ist, dass Forklift ein weiteres Tool ist, das installiert, konfiguriert und verwaltet werden muss. Es erfordert Zugriff auf die vCenter-API, und man muss sein Zuordnungsmodell verstehen (wie es VMware-Netzwerke und storage Kubernetes-Ressourcen übersetzt). Für kleine Umgebungen lohnt sich der Aufwand für die Einrichtung möglicherweise nicht.

Methode B: Manuelle Konvertierung mit virt-v2v

Verwenden Sie „libguestfs virt-v2v“, um VMDK-Dateien in das QCOW2-Format zu konvertieren, und importieren Sie diese anschließend über den Containerized Data Importer (CDI) in KubeVirt. So haben Sie die volle Kontrolle über jeden Schritt des Prozesses, ohne dass Sie über „virt-v2v“ und „kubectl“ hinaus weitere Tools benötigen.

Dieser Ansatz eignet sich am besten für kleinere Umgebungen, isolierte Umgebungen, in denen Forklift nicht installiert werden kann, oder Teams, die jeden Schritt des Konvertierungsprozesses genau nachvollziehen möchten. Er ist zudem die richtige Wahl für VMs, die eine spezielle Behandlung erfordern – beispielsweise benutzerdefinierte Treiber, ungewöhnliche Festplattenlayouts oder nicht standardmäßige Konfigurationen.

Der Nachteil ist ein höherer manueller Aufwand pro VM. Jede Konvertierung erfordert die Ausführung von virt-v2v, das Hochladen des resultierenden Images, die Erstellung des DataVolume und das Schreiben des VirtualMachine-Manifests. Teil 2 dieser Serie führt Schritt für Schritt durch diesen Prozess.

Pfad C: Neuaufbau (Plattformwechsel)

Anstatt die VM zu migrieren, sollten Sie die Anwendung containerisieren oder auf Kubernetes-nativen Diensten neu aufbauen. Wenn eine Workload bereits zustandslos ist, einen Standard-Anwendungsstack (Node.js, Python, Java) ausführt und nicht von spezifischen Konfigurationen auf Betriebssystemebene abhängt, eignet sie sich besser für die Containerisierung als für eine VM-Migration.

Dies ist zwar mit dem größten Aufwand pro Workload verbunden, führt aber langfristig zur besten Architektur. Container sind schlanker, schneller bereitzustellen und einfacher zu skalieren als VMs. Wenn Sie sich bereits die Mühe machen, von VMware abzuweichen, sollten Sie überlegen, ob bestimmte Workloads VMs nicht ganz überspringen sollten.

Tipp: Die meisten Unternehmen nutzen eine Kombination aus allen drei Vorgehensweisen. Containerisieren Sie, was sich containerisieren lässt (Vorgehensweise C), migrieren Sie Standard-VMs mit Forklift in großen Mengen (Vorgehensweise A) und konvertieren Sie die kniffligen Fälle manuell mit virt-v2v (Vorgehensweise B). Ordnen Sie jede VM in Ihrem Bestand der Vorgehensweise zu, die am sinnvollsten ist.

flowchart TD
    Start[VM from VMware inventory]
    Q1{Stateless app
+ standard stack?}
    Q2{50+ similar VMs
to migrate?}
    Q3{Special drivers
or unusual config?}

    Start --> Q1
    Q1 -->|Yes| Rebuild["Path C: Rebuild as container
(highest long-term value)"]
    Q1 -->|No| Q2
    Q2 -->|Yes| Forklift["Path A: Forklift
(automated bulk migration)"]
    Q2 -->|No| Q3
    Q3 -->|Yes| V2V["Path B: virt-v2v manual
(full control per VM)"]
    Q3 -->|No| V2V

Schritt 4: Entwerfen Sie Ihre Zielarchitektur

Nachdem Sie Ihre Bestandsaufnahme abgeschlossen und Migrationspfade zugewiesen haben, müssen Sie den Kubernetes-Cluster entwerfen, in dem Ihre VMs gehostet werden sollen. Dabei erfordern drei Bereiche die größte Aufmerksamkeit: Rechenleistung, storage und Netzwerk.

Berechnung der Größe

Jede KubeVirt-VM läuft in einem virt-launcher-Pod. Der Pod beansprucht dieselbe CPU-Leistung und denselben Arbeitsspeicher wie die VM, sodass Ihre Kubernetes-Knoten über ausreichend Kapazität verfügen müssen, um die zu migrierenden VMs sowie den entsprechenden Overhead zu hosten.

Planen Sie die gleiche Gesamtkapazität wie für Ihre VMware-Umgebung ein, zuzüglich 15–20 % Overhead für die Kubernetes-Systemkomponenten (kubelet, kube-proxy, CoreDNS) und den KubeVirt-Stack selbst (virt-controller, virt-handler, virt-api). Wenn Sie auf denselben Knoten eine storage wie Ceph betreiben, rechnen Sie weitere 10–15 % für storage hinzu.

Für GPU-Workloads muss IOMMU im BIOS und im Kernel aktiviert sein. Hinzufügen intel_iommu=on oder amd_iommu=on in Ihrer GRUB-Konfiguration, je nach Prozessorhersteller. Der GPU-Passthrough in KubeVirt funktioniert gut, erfordert jedoch eine Vorabkonfiguration, von der Sie nicht erst am Tag der Migration feststellen möchten, dass sie notwendig ist.

Storage

Dies ist die wichtigste Entscheidung bei der Gestaltung Ihrer Zielarchitektur. Ihre storage bestimmt, ob Sie die Live-Migration nutzen können, wie Ihre Backups funktionieren und welche Leistung Ihre VMs erzielen werden.

• Ceph (über Rook): Verteilter storage den RWX-Zugriffsmodus unterstützt, der für die Live-Migration erforderlich ist. Bewährt im Produktioneinsatz und praxiserprobt, jedoch mit höherer betrieblicher Komplexität. Wenn Sie eine große VMware-Umgebung migrieren und Live-Migration benötigen, ist Ceph die Standardwahl.

• Longhorn: Einfacherer verteilter storage, besonders gut geeignet für mittelgroße Bereitstellungen. Die Unterstützung für KubeVirt bei Longhorn wird immer besser, und für kleinere Teams ist die Bedienung einfacher als bei Ceph.

• Lokaler storage Hostpath-Provisioner): Bietet die beste reine Leistung, da kein Netzwerk-Overhead entsteht. VMs, die lokalen storage nutzen, storage jedoch an den Knoten gebunden, auf dem sich ihre Daten befinden. Keine Unterstützung für Live-Migration – für Wartungsarbeiten am Knoten muss die VM heruntergefahren werden.

• Cloud-Volumes (EBS, Persistent Disk): Diese Option eignet sich, wenn Sie Kubernetes bei einem Cloud-Anbieter betreiben. Beachten Sie dabei die Einschränkungen hinsichtlich einer einzigen Verfügbarkeitszone für Block-Volumes sowie die IOPS-Grenzwerte der Standard-Volume-Typen.

Warnung: Für die Live-Migration ist storage gemeinsamer storage dem Zugriffsmodus RWX (ReadWriteMany) erforderlich. Wenn Sie sich für lokalen storage entscheiden, können VMs nicht zwischen Knoten migriert werden. Bei der Wartung von Knoten, bei Kernel-Upgrades und bei Hardwareausfällen müssen die VMs heruntergefahren und neu gestartet werden. Wägen Sie diese Vor- und Nachteile bewusst ab.

Netzwerken

Die Standard-Pod-Vernetzung über Calico oder Cilium funktioniert bei den meisten VMs. Jede VM erhält eine Pod-IP-Adresse und kann über das Standard-Kubernetes-Netzwerk mit anderen Pods, Diensten und externen Endpunkten kommunizieren.

Die Probleme beginnen, wenn Ihre VMs einen Netzwerkzugang auf Layer-2-Ebene benötigen. Viele ältere Anwendungen erwarten Broadcast-Verkehr, nutzen ARP zur Erkennung oder benötigen bestimmte VLANs. Standardmäßige Kubernetes-CNIs arbeiten auf Layer-3-Ebene (IP-Routing), was bedeutet, dass diese Layer-2-Anforderungen nicht erfüllt werden können.

Für VMs, die Layer-2-Zugriff benötigen, installieren Sie Multus CNI und erstellen Sie NetworkAttachmentDefinitions mit den Plugins „bridge“ oder „macvtap“. Mit Multus können Sie mehrere Netzwerkschnittstellen an einen einzelnen Pod (oder eine einzelne VM) anbinden, sodass eine VM über eine Schnittstelle im Pod-Netzwerk und eine weitere in einem über eine Bridge verbundenen Layer-2-Segment verfügen kann.

Schritt 5: Planen Sie Ihre Netzwerkmigration

Das Netzwerk verdient einen eigenen Abschnitt, da hier die meisten Migrationen von VMware zu KubeVirt scheitern. Storage knapp dahinter, doch Fehler im Netzwerk sind subtiler und schwerer zu beheben.

IP-Adressverwaltung

VMs in KubeVirt erhalten standardmäßig Pod-IP-Adressen, die vom CNI zugewiesen werden und sich ändern, wenn die VM auf einen anderen Knoten umverteilt wird. Wenn Ihre VMs fest codierte IP-Adressen, statische DNS-Einträge oder Anwendungskonfigurationen haben, die auf bestimmte IP-Adressen verweisen, haben Sie zwei Möglichkeiten:

• Verwenden Sie Multus zusammen mit einem Bridge-Plugin und einem DHCP-Server im selben Layer-2-Segment, damit die virtuellen Maschinen vorhersehbare IP-Adressen von Ihrer bestehenden DHCP-Infrastruktur erhalten.
• Weisen Sie bei der Erstellung der VM statische IP-Adressen über cloud-init oder den QEMU-Gast-Agenten zu.

Keine der beiden Optionen ist so reibungslos wie das Netzwerkmodell von VMware, bei dem eine VM ihre IP-Adresse beibehält, unabhängig davon, auf welchem Host sie ausgeführt wird. Planen Sie diese Schwierigkeiten ein und nehmen Sie sich Zeit für Tests.

Zuordnung von NSX zu Kubernetes

Wenn Sie NSX-T oder NSX-V einsetzen, benötigt jedes Segment oder jede Portgruppe eine entsprechende „NetworkAttachmentDefinition“ in Kubernetes. Dokumentieren Sie jedes Segment, welche VMs es nutzen und welche Layer-2- oder Layer-3-Eigenschaften es bietet. Diese Zuordnung ist zwar mühsam, aber unerlässlich – wenn bei der Migration ein Netzwerksegment übersehen wird, bedeutet dies, dass eine VM ohne Verbindung zu einer kritischen Abhängigkeit gestartet wird.

DNS-Aktualisierungen

Aktualisieren Sie die DNS-Einträge so, dass sie auf die neuen IP-Adressen der KubeVirt-VMs verweisen. Planen Sie eine Übergangsphase ein, in der sowohl die VMware- als auch die KubeVirt-Version einer VM gleichzeitig laufen, und nutzen Sie Änderungen am DNS oder am Load Balancer, um den Datenverkehr umzuleiten. Führen Sie die Umstellung des DNS und die Außerbetriebnahme der VMware-VM nicht im selben Wartungsfenster durch.

Warnung: Reibungsverluste auf Layer 2 und Layer 3 sind das größte technische Problem beim KubeVirt-Netzwerk. Standardmäßige Kubernetes-CNIs arbeiten auf Layer 3 (IP-Routing), doch viele ältere VMs erwarten ein Verhalten auf Layer 2 (ARP, Broadcast, DHCP). Wenn Ihre VMs Layer 2 benötigen, müssen Sie Multus mit einem Bridge- oder macvtap-Plugin verwenden. Testen Sie diese Konfiguration frühzeitig während der Migration und nicht erst während der Umstellung in der Produktion.

Schritt 6: Erstellen Sie Ihr Migrations-Runbook

Ein schrittweises Vorgehen verringert das Risiko. Versuchen Sie nicht, alles auf einmal zu migrieren.

Phase 1: Entwicklungs-/Test-VMs (Woche 1–2)

Beginnen Sie mit nicht kritischen Entwicklungs- und Test-VMs. Diese dienen als Ihre Lernumgebung. Migrieren Sie diese, überprüfen Sie, ob die Netzwerkverbindungen funktionieren, testen Sie storage und vergewissern Sie sich, dass die Anwendungen ordnungsgemäß funktionieren. Nutzen Sie diese Phase, um das Vertrauen des Teams in die Tools zu stärken und Probleme in einer risikoarmen Umgebung aufzudecken.

Dokumentieren Sie jedes auftretende Problem und wie Sie es gelöst haben. Diese Dokumentation dient Ihnen als Leitfaden für die Produktionsphasen.

Phase 2: Stateless Production VMs (Woche 3–4)

Migrieren Sie Produktions-VMs, die zustandslos oder leicht austauschbar sind: Webserver, API-Gateways, Reverse-Proxys und ähnliche Workloads. Betreiben Sie diese ein bis zwei Wochen lang parallel zu den VMware-Versionen und leiten Sie den Datenverkehr schrittweise über DNS-Änderungen oder Aktualisierungen des Load Balancers um.

In dieser Phase wird überprüft, ob KubeVirt den Produktionsdatenverkehr bewältigen kann und ob Ihre Workflows für Überwachung, Alarmierung und Störungsbehebung mit der neuen Plattform kompatibel sind.

Phase 3: Stateful-Produktions-VMs (Woche 5–8)

Datenbanken, Dateiserver und VMs mit persistentem Zustand sind am schwierigsten zu migrieren. Sie erfordern eine sorgfältige Datenmigration, die Überprüfung der Datenintegrität sowie geplante Wartungsfenster für die endgültige Umstellung.

Bei Datenbanken sollten Sie die Replikation nutzen, um die VMware- und KubeVirt-Instanzen während der Umstellung synchron zu halten. Führen Sie die Umstellung durch, indem Sie die KubeVirt-Replik aktivieren und die Verbindungszeichenfolgen aktualisieren. Dies minimiert Ausfallzeiten und bietet Ihnen eine schnelle Möglichkeit zum Rollback.

Phase 4: VMware außer Betrieb nehmen (ab Woche 9)

Sobald alle Workloads auf KubeVirt validiert sind, nehmen Sie Ihre ESXi-Hosts und vCenter außer Betrieb. Weisen Sie die Hardware Kubernetes-Knoten zu, sofern sie Ihren Anforderungen entspricht, oder entsorgen Sie sie. Kündigen Sie Ihre VMware-Lizenzen oder stufen Sie diese herunter.

Überstürzen Sie diese Phase nicht. Lassen Sie VMware weiterlaufen, bis Sie sicher sind, dass alle migrierten Workloads stabil laufen. Die Kosten für den Betrieb beider Plattformen für ein oder zwei zusätzliche Wochen sind weitaus geringer als die Kosten einer fehlgeschlagenen Migration ohne Rollback.

Risikominderung

Vier Strategien, die Ihnen bei der Migration helfen:

Rollback-Strategie. Halten Sie VMware während des gesamten Migrationszeitraums in Betrieb. Stellen Sie für jede VM sicher, dass ein Rollback auf die VMware-Version möglich ist, bis die KubeVirt-Version in der Produktion über mindestens einen vollständigen Geschäftszyklus (in der Regel ein bis zwei Wochen) validiert wurde.

Leistungs-Baseline. Führen Sie vor der Migration Benchmark-Tests für wichtige VMs auf VMware durch. Erfassen Sie die CPU-Auslastung, den Speicherverbrauch, die Festplatten-IOPS und den Netzwerkdurchsatz. Führen Sie nach der Migration dieselben Benchmark-Tests auf KubeVirt durch und vergleichen Sie die Ergebnisse. Sollte die Leistung deutlich nachlassen, sollten Sie die Ursache untersuchen, bevor Sie die nächste Gruppe migrieren.

Parallelbetrieb. Planen Sie ein, beide Plattformen zwei bis vier Wochen lang gleichzeitig zu betreiben. Dies verursacht zwar höhere Infrastrukturkosten, vermeidet jedoch das Risiko einer „Big-Bang“-Migration, bei der alles auf einmal umgestellt wird und es keine Ausweichlösung gibt.

Kompetenzlücke. Ihr Team kennt sich mit VMware aus. Es ist mit vCenter, ESXi, vMotion und dem VMware-Ökosystem vertraut. KubeVirt nutzt andere Tools: kubectl, virtctl, Kubernetes RBAC und YAML-Manifeste. Planen Sie Schulungen ein, bevor die Migration beginnt, und nicht erst währenddessen. Das KubeVirt-Benutzerhandbuch und die anderen Tutorials dieser Reihe sind ein guter Ausgangspunkt.

Nächste Schritte

Nachdem Sie Ihren Plan aufgestellt haben, können Sie mit der praktischen Arbeit beginnen:

• Konvertierung von VMware-VMs zu KubeVirt: Eine Schritt-für-Schritt-Anleitung mit virt-v2v (in Kürze verfügbar) – Teil 2 dieser Reihe behandelt den eigentlichen Konvertierungsprozess
• Fehlerbehebung bei KubeVirt: CNI-Konflikte, CDI-Fehler und gängige Lösungen – für Probleme, auf die Sie bei der Migration stoßen werden
• KubeVirt auf einem Kubernetes-Cluster installieren – Richten Sie Ihre Zielumgebung ein, bevor Sie mit der Migration beginnen

Zusammenfassung

Die Migration von VMware zu KubeVirt ist ein umfangreiches Infrastrukturprojekt, das jedoch mit dem richtigen Plan durchaus realisierbar ist. Beginnen Sie mit einer Bestandsaufnahme Ihrer VMware-Umgebung und dokumentieren Sie die Konfiguration, Abhängigkeiten und Netzwerkanforderungen jeder VM. Ordnen Sie VMware-Konzepte ihren KubeVirt-Entsprechungen zu, damit Ihr Team die neue Plattform versteht. Wählen Sie Migrationspfade aus – „Forklift“ für die Massenmigration, „virt-v2v“ für manuelle Steuerung und Containerisierung, wo dies sinnvoll ist. Entwerfen Sie Ihre Zielarchitektur unter besonderer Berücksichtigung von storage für die Live-Migration storage Shared storage erforderlich) und Netzwerk (Layer-2-Reibungsverluste sind die häufigste Fehlerquelle). Führen Sie die Migration schrittweise durch, beginnend mit Dev/Test und bis hin zu zustandsbehafteten Produktions-Workloads. Lassen Sie VMware als Rollback-Option weiterlaufen, bis Sie von der neuen Plattform überzeugt sind.

Die Planungsphase bildet das Fundament. Wenn sie gut gemacht ist, verläuft die Umsetzung reibungslos. Überspringt man sie, verbringt man mehr Zeit damit, Probleme zu lösen, als mit der Migration selbst.