VMware-Exit: Wie eine Migration von ESXi zu Proxmox VE tatsächlich abläuft
Die Entscheidung ist gefallen, die Umsetzung steht an. Dieser Beitrag beschreibt die drei praktikablen Wege, eine virtuelle Maschine von ESXi nach Proxmox VE zu holen – und die Reihenfolge, die verhindert, dass am Montagmorgen etwas fehlt.
Das Wichtigste in Kürze
- Seit Proxmox VE 8.2 gibt es einen eingebauten Import-Assistenten, der sich direkt mit einem ESXi-Host verbindet – für die meisten virtuellen Maschinen ist das der kürzeste Weg.
- Der eigentliche Aufwand steckt nicht im Kopiervorgang, sondern in Treiberwechsel, Sicherungsumbau und Dokumentation.
- Wer die alte Umgebung mehrere Wochen stehen lässt, hat jederzeit einen Rückweg – und braucht deshalb kein Migrationswochenende mit Nervenkrieg.
Ob Proxmox VE für Ihr Unternehmen überhaupt die richtige Plattform ist, haben wir an anderer Stelle abgewogen: In Proxmox VE oder VMware? geht es um die Entscheidung. Dieser Beitrag setzt danach an und beschreibt die Durchführung – für den Fall, dass die Entscheidung gefallen ist.
Vorweg die gute Nachricht: Eine Migration ist heute deutlich unspektakulärer als ihr Ruf. Die Werkzeuge sind ausgereift, und der überwiegende Teil einer mittelständischen Umgebung wandert ohne Handarbeit hinüber. Die Fälle, die Aufwand machen, lassen sich vorher identifizieren – vorausgesetzt, man nimmt sich die Zeit dafür.
Was vor dem ersten Import geklärt sein muss
Die häufigste Ursache für eine unglückliche Migration ist nicht ein technischer Fehler, sondern eine fehlende Bestandsaufnahme. Vier Punkte gehören vorher auf Papier:
- Welche virtuellen Maschinen gibt es wirklich? Erfahrungsgemäß findet sich in jeder gewachsenen Umgebung mindestens ein System, das seit Jahren läuft und das niemand vermisst hätte. Jede VM, die nicht mitwandert, spart Aufwand und Speicher.
- Welche Herstellerfreigaben gelten? Wenn Ihre Branchen-, ERP- oder Praxissoftware ausschließlich für vSphere freigegeben ist, endet die Diskussion an dieser Stelle – unabhängig davon, ob es technisch funktionieren würde.
- Was hängt an einer festen MAC-Adresse oder einem Dongle? Lizenzserver, die sich an die Netzwerkkarte binden, und USB-Dongles sind die beiden Themen, die nach einer Migration am häufigsten für einen Anruf sorgen.
- Wie sieht das Speicherkonzept auf der Zielseite aus? Lokale Datenträger mit Replikation, ein vorhandenes zentrales Speichersystem oder ein verteilter Verbund mit Ceph – diese Entscheidung prägt die neue Umgebung stärker als der Hypervisor selbst. Eine Entscheidungshilfe steht in Ceph oder ZFS?
Drei Wege, eine virtuelle Maschine zu übernehmen
In der Praxis reichen drei Verfahren aus. Welches passt, hängt davon ab, ob der ESXi-Host noch erreichbar ist und wie exotisch das Gastsystem ist.
| Weg | Wann sinnvoll | Was zu beachten ist |
|---|---|---|
| Import-Assistent von Proxmox VE | Der Regelfall. Der ESXi-Host läuft und ist über das Netz erreichbar. | Verfügbar ab Proxmox VE 8.2. Verbindet sich über die Schnittstelle des Hosts und übernimmt Konfiguration und Datenträger in einem Durchgang. |
Export als OVF, Import per qm importovf |
Der Host ist nicht mehr erreichbar, oder es liegen bereits fertige Vorlagen als OVF vor. | Braucht zwischenzeitlich Speicherplatz für den Export. Dafür unabhängig von der Erreichbarkeit der Altumgebung. |
virt-v2v |
Nachzügler und Sonderfälle, bei denen die ersten beiden Wege stolpern. | Kann Treiberanpassungen im Gastsystem übernehmen. Aufwendiger, dafür sehr robust. |
Praktisch heißt das: Man beginnt mit dem Import-Assistenten, und die wenigen Systeme, die sich damit nicht überzeugen lassen, bekommen einen der beiden anderen Wege. Eine Umgebung komplett über den aufwendigsten Weg zu migrieren, nur weil ein einzelnes System Schwierigkeiten macht, ist verlorene Zeit.
Der Windows-Sonderfall: VirtIO
Linux-Gastsysteme bringen die nötigen Treiber in aller Regel mit und starten nach dem Import ohne Zutun. Bei Windows ist das anders, und genau hier entstehen die meisten Fehlschläge.
Proxmox VE nutzt für Datenträger und Netzwerkkarte sogenannte paravirtualisierte Treiber (VirtIO). Sie sind spürbar schneller als emulierte Geräte – aber ein Windows, das diese Treiber nicht kennt, findet nach dem Umstellen seine eigene Systemplatte nicht mehr und bleibt beim Start stehen. Die Reihenfolge ist deshalb entscheidend:
- Noch auf der alten Umgebung: VirtIO-Treiber im laufenden Windows installieren, solange das System normal startet. Sie werden dabei nur hinterlegt, nicht aktiv genutzt.
- Ebenfalls vorher: die VMware-Werkzeuge (VMware Tools) entfernen. Bleiben sie liegen, führt das später zu Treiberkonflikten und ist mühsam zu bereinigen.
-
Nach dem Import: den Datenträger auf
VirtIO SCSI singleund die Netzwerkkarte auf VirtIO umstellen. - Zum Schluss: den QEMU-Gastagenten installieren. Er sorgt dafür, dass Sicherungen dateisystemkonsistent laufen und ein sauberes Herunterfahren aus der Oberfläche heraus funktioniert.
Wurde die Treiberinstallation vergessen und startet das System nicht mehr, hilft ein Zwischenschritt: den Datenträger vorübergehend als emulierten SATA-Datenträger einbinden, Windows normal starten lassen, die Treiber nachinstallieren und erst dann auf VirtIO wechseln. Es ist kein Grund, den Import zu wiederholen.
Wie ein Migrationswochenende sinnvoll aufgebaut ist
Ein bewährtes Vorgehen verteilt die Migration über mehrere Wochen, statt alles in eine Nacht zu pressen:
- Erst die Sicherung, dann die Systeme. Die neue Umgebung braucht ein funktionierendes Sicherungsverfahren ab dem ersten produktiven System – nicht danach. Das ist der Schritt, der am häufigsten nach hinten geschoben wird und am teuersten ist, wenn dazwischen etwas passiert.
- Mit unkritischen Systemen anfangen. Test-, Druck- und Nebendienste zuerst. Sie liefern realistische Zeitwerte: Wer weiß, dass eine 200-GB-VM in der eigenen Umgebung vierzig Minuten braucht, kann den Rest verlässlich planen.
- Die alte Umgebung stehen lassen. Solange der ESXi-Host läuft, ist ein Rücksprung jederzeit möglich. Abgebaut wird erst, wenn der neue Stand mehrere Wochen unauffällig gelaufen ist – nicht am Montag nach der Umstellung.
- Nach dem Umzug einmal wiederherstellen. Eine Sicherung auf einer neuen Plattform ist erst dann eine Sicherung, wenn eine Rücksicherung nachweislich funktioniert hat. Wie so ein Test aussieht, steht in Backup getestet – oder nur gesichert?
- Dokumentation mitziehen. Neue Adressen, neue Zugänge, neuer Wiederanlaufplan. Was jetzt nicht aufgeschrieben wird, fehlt im Ernstfall.
Aufwand, Ausfallzeit und Zuständigkeit
Die Frage, die in der Praxis zuerst kommt, lautet: Wie lange steht der Betrieb still? Die Antwort fällt meist beruhigender aus als erwartet. Pro virtueller Maschine ist die Ausfallzeit im Wesentlichen die Kopierzeit der Datenträger – das ist eine Frage von Größe und Netzwerkanbindung, nicht von Stunden am Stück für die gesamte Umgebung. Da die Systeme einzeln umziehen, verteilt sich das auf mehrere kurze Fenster.
Was tatsächlich Zeit kostet und in jeder Kalkulation stehen sollte: die Bestandsaufnahme vorab, der Umbau der Sicherung, das Nacharbeiten bei Windows-Systemen, die Anpassung von Überwachung und Dokumentation sowie eine Einarbeitung für diejenigen, die die Umgebung künftig bedienen. Die reine Lizenzersparnis auf der einen Seite gegen diesen Aufwand auf der anderen – erst dann ergibt die Rechnung ein ehrliches Bild.
Wo eine Migration nicht sinnvoll ist
- Bei bindenden Herstellerfreigaben. Wenn die zentrale Fachanwendung nur auf vSphere unterstützt wird, wiegt das schwerer als jede Lizenzersparnis.
- Wenn die vorhandene Umgebung läuft und die Kosten vertretbar sind. Es gibt keinen Grund für Aktionismus. Der nächste Verlängerungstermin ist früh genug für eine erneute Prüfung.
- Wenn niemand die neue Plattform betreuen kann. Eine gesparte Lizenz nützt wenig, wenn im Störungsfall niemand weiß, wo er nachsehen muss. Die Frage nach der Zuständigkeit gehört vor die Frage nach dem Produkt.
- Bei einem einzelnen Server ohne Hochverfügbarkeit. Beide Plattformen erfüllen den Zweck. Investieren Sie das gesparte Geld lieber in Ihre Datensicherung.
Fazit
Der technische Teil einer Migration von ESXi zu Proxmox VE ist heute Routine. Was über Erfolg oder Ärger entscheidet, liegt davor und dahinter: eine ehrliche Bestandsaufnahme, die richtige Reihenfolge bei Windows-Systemen, eine Sicherung, die vom ersten Tag an greift, und ein Rückweg, den man mehrere Wochen offenhält.
Wir planen und begleiten solche Umzüge regelmäßig – von der Bestandsaufnahme bis zum Abbau der Altumgebung. Details dazu unter Proxmox-Migration und Server & Virtualisierung.
