Hypervisor-Wechsel: erst planen, dann migrieren VM-Migration im Praxistest: Wo Projekte wirklich scheitern

Mit dem Ende des General Support für VMware vSphere 8 am 11. Oktober 2027 steht in vielen Unternehmen nun ein Hypervisor-Wechsel an. Andreas Engel von NetApp erklärt, was vor der Plattformwahl geklärt sein sollte, welches Migrationsverfahren zu welchem Workload passt und warum Multi-Hypervisor-Betrieb auch die darunterliegende Infrastruktur betrifft.

In Migrationsprojekten zeigt sich immer wieder dasselbe Bild: Ein Unternehmen will seinen Hypervisor wechseln und entscheidet sich für eine neue Plattform. Wenn die eigentliche Arbeit beginnt, stellt sich schnell heraus, dass für einen Großteil der virtuellen Maschinen (VM) die Grundlage fehlt. Es gibt weder einen dokumentierten Applikationsbezug noch klare Zuständigkeiten. Was als technisches Migrationsprojekt geplant war, wird zur Detektivarbeit.

Werkzeuge, um virtuelle Maschinen von einer Plattform auf eine andere zu übertragen, sind vorhanden. Was häufig fehlt, ist Transparenz über die eigene Infrastruktur. Sie ist das Fundament jeder Migration und muss bereits vor dem ersten migrierten Workload geschaffen werden.

Strategie-Entscheidung vor Plattform-Wahl

Bevor eine Hypervisor-Entscheidung getroffen werden kann, brauchen IT-Abteilungen Klarheit über das, was sie aktuell betreiben. Die relevanten Fragen lauten: Welche Applikationen laufen auf welchen virtuellen Maschinen? Welche Abhängigkeiten bestehen zwischen Systemen? Wer trägt für welchen Workload die fachliche Verantwortung? Und welche Verfügbarkeitsanforderungen gelten für die einzelnen Dienste?

Dieser Prozess wird in der Praxis als Application-Owner-Mapping bezeichnet und ist ein notwendiger Schritt vor der Plattformevaluation. Er schafft die Datenbasis für alle nachgelagerten Entscheidungen: von der Klassifizierung der Workloads über die Auswahl des Migrationsverfahrens und die Planung von Wartungsfenstern bis hin zur Einbindung der richtigen Freigabestellen.

Erst auf dieser Grundlage lässt sich sinnvoll beurteilen, welche Workloads überhaupt migriert werden müssen, welche möglicherweise konsolidiert oder außer Betrieb genommen werden können und für welche Anwendungen eine bestimmte Zielplattform aufgrund technischer oder regulatorischer Anforderungen vorgegeben ist.

Windows Admin Center erhält Migrationsassistent für VMware

So migrieren Sie VMs aus VMware vSphere zu Hyper-V – kostenfrei

Das passende Migrationsverfahren für jeden Workload

Nach der Bestandsaufnahme stellt sich die Frage nach dem Migrationsverfahren. Denn nicht jede VM lässt sich mit demselben Vorgehen migrieren. Ausschlaggebend sind unter anderem die tolerierbare Ausfallzeit, die Datenänderungsrate sowie die technischen Möglichkeiten der Quell- und Zielplattform.

Bei einer Cold-Migration wird das System heruntergefahren, auf die neue Plattform übertragen beziehungsweise konvertiert und dort wieder gestartet. Das Verfahren ist vergleichsweise einfach und eignet sich insbesondere für Workloads, bei denen ein entsprechendes Wartungsfenster zur Verfügung steht.

Bei einer replizierenden Migration werden die Daten bereits im laufenden Betrieb auf die Zielplattform übertragen. Für den finalen Cutover wird der Workload auf der Quellplattform gestoppt, die letzten Änderungen werden synchronisiert und das System anschließend auf der Zielplattform gestartet. Dadurch lässt sich die tatsächliche Ausfallzeit erheblich reduzieren.

Eine echte Live-Migration zwischen unterschiedlichen Hypervisor-Plattformen ist dagegen technisch nur in Ausnahmefällen möglich. Verfahren wie vMotion funktionieren innerhalb einer entsprechend integrierten Virtualisierungsplattform, lassen sich aber nicht ohne Weiteres auf einen Wechsel zwischen unterschiedlichen Hypervisoren übertragen.

Für Anwendungen, bei denen selbst eine kurze Unterbrechung nicht akzeptabel ist, müssen deshalb häufig Verfahren oberhalb der Virtualisierungsebene eingesetzt werden. Dazu gehören beispielsweise Applikationscluster, Datenbankreplikation, Load Balancing oder ein paralleler Betrieb von Quell- und Zielsystem während der Umstellung.

Welches Verfahren für welchen Workload geeignet ist, sollte daher bereits in der Planungsphase festgelegt werden und nicht erst während der eigentlichen Migration.

Freigaben und Verantwortliche

Hier liegt der Punkt, an dem auch technisch gut vorbereitete Migrationsprojekte ins Stocken geraten. Denn praktisch jede Migration erfordert irgendwann einen Cutover: einen definierten Zeitpunkt, zu dem der Workload auf der bisherigen Plattform gestoppt und auf der neuen Plattform produktiv genommen wird.

Dafür braucht es neben einem definierten Zeitpunkt auch eine Genehmigung durch einen verantwortlichen Ansprechpartner.

In Unternehmen mit hunderten oder tausenden VMs ist genau das oft eine der größten Herausforderungen. Anwendungsverantwortliche sind nicht dokumentiert, Zuständigkeiten haben sich durch Reorganisationen verschoben und historisch gewachsene Systeme haben keinen klar benannten Owner mehr. Selbst wenn sämtliche technischen Voraussetzungen erfüllt sind, kann die Migration ohne entsprechende Freigabe nicht durchgeführt werden.

Für einen möglichst geringen Aufwand sollte der operative Rahmen daher schon vor der ersten Migration stehen.

Das Rechenzentrum zu teuer, ein Hyperscaler zu unsicher

Was tun, wenn die VMware-Preise explodieren?

Das Ökosystem mitdenken, nicht nur den Hypervisor

Die öffentliche Debatte verengt sich häufig auf Lizenzkosten und den Funktionsumfang der jeweiligen Virtualisierungsplattform. Das greift jedoch zu kurz. Kein Hypervisor arbeitet isoliert. Er muss mit Backup-Lösungen zusammenarbeiten, Monitoring-Systeme einbinden, Storage-Infrastrukturen ansprechen und in bestehende Automatisierungsprozesse integriert werden.

Ist beispielsweise der bisherige Backup-Anbieter für die neue Plattform nicht zertifiziert oder fehlen Schnittstellen zu bestehenden Betriebsprozessen, entsteht schnell ein zusätzliches Folgeprojekt, das den ursprünglichen Migrationsaufwand in Kosten und Zeitbedarf deutlich übersteigen kann.

Besonders relevant wird das Ökosystem bei Enterprise-Anforderungen wie Hochverfügbarkeit über mehrere Standorte, Ransomware-Schutz, Backup und Recovery oder der schnellen Bereitstellung von Datenkopien. Diese Fähigkeiten müssen nicht zwangsläufig Bestandteil des Hypervisors sein. Moderne Storage-Plattformen können einen Teil dieser Datenservices unabhängig von der darüberliegenden Virtualisierungsplattform bereitstellen.

Das wird insbesondere in Multi-Hypervisor-Umgebungen interessant: Liegen Daten auf einer gemeinsamen Storage-Infrastruktur, können Funktionen wie Snapshots, Replikation, Cloning oder Disaster Recovery unabhängig davon genutzt werden, ob ein Workload auf VMware, Hyper-V, Proxmox oder einer containerbasierten Virtualisierungsplattform betrieben wird.

Die Storage-Schicht wird damit zu einer Konstante in einer Infrastruktur, deren Compute-Plattformen sich zunehmend verändern.

Gefragte Alternativen: Proxmox, Hyper-V, OpenShift

Bei deutschen Unternehmenskunden sind aktuell vor allem drei Alternativen im Gespräch. Neben Microsoft Hyper-V und Red Hat OpenShift Virtualization ist vor allem Proxmox besonders gefragt. Die europäische Open-Source-Plattform basiert auf KVM als Linux-Kernel-Komponente und bietet Unternehmen eine Alternative zu klassischen proprietären Virtualisierungsplattformen.

Gerade im Zusammenhang mit digitaler Souveränität ist dieses Modell für öffentliche Verwaltungen, Kliniken, Finanzinstitute und andere regulierte Organisationen interessant. Ob eine Plattform konkrete Compliance-Anforderungen erfüllt, muss allerdings immer anhand des jeweiligen regulatorischen und betrieblichen Rahmens bewertet werden.

Mit der Expansion nach Nordamerika und dem angekündigten 24/7-Follow-the-Sun-Support adressiert Proxmox zudem einen Punkt, der insbesondere bei größeren Enterprise-Kunden bislang häufig kritisch bewertet wurde: die weltweite Verfügbarkeit von Herstellersupport. Damit entwickelt sich nicht nur die technische Plattform weiter, sondern auch die für einen internationalen Enterprise-Betrieb notwendige Support-Struktur.

Bei der Bewertung bleiben dennoch die Anforderungen des gesamten Infrastruktur-Stacks entscheidend. Funktionen wie standortübergreifende Hochverfügbarkeit, Storage-basierter Ransomware-Schutz oder weitergehende Datenservices können beispielsweise über die Storage-Infrastruktur bereitgestellt werden. Solche Anforderungen sollten deshalb von Beginn an Teil der Architekturentscheidung sein.

Multi-Hypervisor: die neue operative Normalität

Eine Entscheidung für eine einzige Virtualisierungsplattform ist in vielen Unternehmensumgebungen zunehmend unrealistisch. VDI-Workloads mit speziellen GPU-Anforderungen können andere Voraussetzungen haben als klassische Applikationsserver. Legacy-Anwendungen koexistieren mit containerisierten Workloads und regulatorische oder organisatorische Vorgaben können beeinflussen, welche Plattform für bestimmte Anwendungen verwendet wird.

Multi-Hypervisor-Betrieb ist damit nicht zwangsläufig eine temporäre Übergangsphase, sondern kann zu einem dauerhaften Betriebszustand werden, der strukturiert gemanagt werden muss.

Das verändert auch die Rolle der darunterliegenden Infrastruktur. Je stärker Datenservices an einen einzelnen Hypervisor gekoppelt sind, desto größer werden die Abhängigkeiten bei einem späteren Plattformwechsel.

Eine gemeinsame Storage- und Datenmanagement-Ebene kann hier bewusst als Abstraktionsschicht dienen. Snapshots, Replikation, Backup-Integration oder Disaster-Recovery-Konzepte bleiben damit möglichst unabhängig von der jeweiligen Compute-Plattform. Offene Schnittstellen und REST-APIs werden dabei zunehmend wichtig, um VMware, Hyper-V, Proxmox und OpenShift parallel in bestehende Betriebs- und Automatisierungsprozesse einzubinden.

Das Ziel sollte deshalb nicht sein, für jeden Hypervisor eine vollständig separate Infrastruktur aufzubauen. Sinnvoller ist eine Architektur, bei der sich Compute-Plattformen verändern oder parallel betreiben lassen, ohne gleichzeitig die gesamte Datenhaltung und die dazugehörigen Betriebsprozesse neu gestalten zu müssen.

Was jetzt konkret zu tun ist

Der 11. Oktober 2027 ist ein fixer Termin, aber er ist noch weit genug entfernt, um strukturiert vorzugehen. Wer jetzt beginnt, hat die Möglichkeit, Entscheidungen auf Basis technischer und betrieblicher Anforderungen zu treffen. Wer wartet, muss sie möglicherweise unter erheblichem Zeitdruck treffen.

Der erste Schritt ist deshalb kein Technologieprojekt, sondern eine Bestandsaufnahme: Welche Applikationen laufen auf welchen VMs, mit welchen Abhängigkeiten und unter welcher Zuständigkeit? Welche Ausfallzeiten sind akzeptabel? Welche Anforderungen bestehen an Backup, Hochverfügbarkeit und Disaster Recovery? Und welche Teile der bestehenden Infrastruktur sollen unabhängig vom zukünftigen Hypervisor weiterverwendet werden?

Erst wenn diese Fragen beantwortet sind, lassen sich Migrationsverfahren sinnvoll zuordnen, Zeitpläne realistisch aufsetzen und Ökosystemanforderungen vollständig erfassen.

Die eigentliche technische Migration ist häufig der einfachere Teil. Entscheidend ist das Fundament darunter: Transparenz über Anwendungen und Abhängigkeiten, klare Verantwortlichkeiten und eine Infrastruktur, die Daten möglichst unabhängig von der jeweils eingesetzten Virtualisierungsplattform bereitstellt.

Wer diese Ebene von Anfang an mitdenkt, reduziert nicht nur den Aufwand der aktuellen Migration, sondern schafft zugleich die Voraussetzung dafür, beim nächsten Plattformwechsel deutlich flexibler reagieren zu können.

Über den Autor

Andreas Engel ist seit zwölf Jahren bei NetApp und begleitet als Consulting Solutions Architect Virtualization IT-Organisationen durch komplexe Migrationsprojekte – von der Infrastrukturanalyse bis zur produktiven Inbetriebnahme im neuen Umfeld. Seine Schwerpunkte liegen auf Multi-Hypervisor-Umgebungen, Storage-Integration und der strategischen Ausrichtung moderner Rechenzentrumsinfrastrukturen.

(ID:50973829)