Virtualisierung & Proxmox

Von VMware zu Proxmox migrieren: der Weg, den deine VMs wirklich gehen

Der VM-Import ist der einfachste Teil und läuft weitgehend automatisiert. Wehtun werden dir das Storage-Layout, die Netzwerk-Umstellung und der Cutover-Termin. Genau diese drei Stellen planst du vorher, den Rest erledigt das Werkzeug.

5 Kapitel mit allen Befehlen
Zwei Administratoren planen im Serverraum eine Migration
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum die Migration selten am Import scheitert

Eine einzelne VM von ESXi nach Proxmox VE zu holen, ist seit dem integrierten ESXi-Import in Proxmox VE 8.2 keine große Sache mehr. Du bindest den ESXi-Host als Storage ein, wählst die VM aus und ziehst die Disks herüber. Schwierig wird es an den Rändern: Der Bestand ist über Jahre gewachsen, niemand weiß mehr genau, welche VM welche Snapshots, welche RDMs, welche VLAN-Portgruppen und welche Abhängigkeiten hat, und für einen Teil der Systeme gibt es kein realistisches Wartungsfenster.

Dazu kommt, dass Proxmox VE kein vSphere-Klon ist. Es gibt kein VMFS, kein DRS und kein vCenter als zentrale Instanz über allem. Storage bedeutet hier ZFS lokal, LVM-thin, NFS oder Ceph RBD, Hochverfügbarkeit bedeutet ein Cluster mit mindestens drei Nodes, sauberem Quorum und Corosync möglichst auf einem eigenen, latenzarmen Netz. Wer die vSphere-Architektur eins zu eins nachbauen will, landet bei einem Design, das im Betrieb nicht trägt.

Die typischen Fehler wiederholen sich: VMware Tools bleiben in den Gastsystemen zurück, Windows-VMs starten nach dem Umbau auf VirtIO-SCSI nicht mehr, weil der Treiber vorher nicht eingebunden wurde, UEFI-Maschinen laufen ohne passende EFI-Disk ins Leere, das Backup-Konzept wird erst nach dem Cutover angefasst, und die Firewall-Regeln hängen noch an alten Portgruppen. Jeder dieser Punkte ist vermeidbar, wenn er vor dem ersten Import auf der Liste steht.

Miniatur-Szene: ein physischer Server links, virtuelle Maschinen als schwebende Würfel rechts, dazwischen eine Brücke
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Migration in sechs Schritten

  1. 01 Bestand inventarisieren
  2. 02 Zielarchitektur und Storage
  3. 03 Gäste vorbereiten
  4. 04 VMs importieren
  5. 05 Backup und Monitoring
  6. 06 Cutover und Abnahme
Was du mitnimmst

So läuft eine Migration nach Proxmox VE ab

Der Ablauf ist in jedem Projekt derselbe, nur die Größenordnung ändert sich. Wichtig ist die Reihenfolge: Erst steht die Zielplattform, dann ziehen die VMs um, nicht andersherum.

Bestand aufnehmen und Wellen bilden

Du inventarisierst alle VMs mit CPU, RAM, Disk-Layout, Betriebssystem, Portgruppe und VLAN, Snapshots, RDMs und angehängten ISOs. Danach sortierst du nach Risiko: unkritische Test- und Infrastruktursysteme in Welle eins, Fachanwendungen und Datenbanken später. Systeme mit Hardware-Dongles, Fremdsupport oder ISV-Freigabe nur für vSphere klärst du vorher ab, nicht im Wartungsfenster.

Zielarchitektur für Cluster und Storage festlegen

Hier entscheidest du zwischen lokalem ZFS mit Replikation, klassischem NFS oder iSCSI und einem verteilten Ceph-Cluster. Ceph gibt dir Shared Storage und echte Live-Migration, verlangt aber mindestens drei Nodes, ausreichend OSDs und ein getrenntes, schnelles Storage-Netz. Parallel legst du das Netzwerk an: Linux-Bridges wie vmbr0, VLAN-aware statt einer Bridge je VLAN, und ein sauberes Bonding auf den Uplinks.

Gastsysteme vor dem Umzug vorbereiten

In den VMs entfernst du die VMware Tools und installierst den qemu-guest-agent. Bei Windows bindest du die virtio-win-Treiber ein, solange die Maschine noch auf dem alten Controller läuft, sonst gibt es nach dem Import einen INACCESSIBLE_BOOT_DEVICE. Bei Linux prüfst du, ob /etc/fstab auf UUIDs statt auf Gerätenamen zeigt, und baust die initramfs neu, damit die VirtIO-Module beim Boot vorhanden sind.

VMs importieren

Der bequemste Weg ist der ESXi-Import in Proxmox VE: ESXi als Storage anbinden, VM auswählen, Disks übernehmen. Alternativ exportierst du per ovftool eine OVF und liest sie mit qm importovf ein, oder du hängst eine vorhandene vmdk mit qm importdisk an eine leere VM. Nach dem Import setzt du Maschinentyp, BIOS oder OVMF samt EFI-Disk, VirtIO SCSI single als Controller und virtio als Netzwerkmodell und prüfst die MAC-Adresse, wenn DHCP-Reservierungen daran hängen.

Backup, Monitoring und Berechtigungen umstellen

Sicherungen laufen entweder über vzdump-Jobs auf einen Proxmox Backup Server mit Deduplizierung und Verify-Jobs oder über dein bestehendes Produkt, sofern es Proxmox VE unterstützt. Gleichzeitig hängst du die neuen Nodes ins Monitoring, richtest die Proxmox-Firewall auf Cluster-, Node- und VM-Ebene ein und bildest die Rollen aus vCenter über Realms, Gruppen und Rollen nach, am besten gegen dein vorhandenes LDAP oder Active Directory.

Cutover fahren und nacharbeiten

Pro Welle planst du ein Fenster mit definierter Downtime je VM, einem Test nach dem Start und einem Rückfallpfad auf die noch vorhandene ESXi-Maschine. Nach dem Umzug prüfst du Performance unter Last, Ballooning und CPU-Typ, räumst alte Snapshots ab und schaltest die Quellsysteme erst frei, wenn mindestens ein vollständiger Backup-Zyklus mit Restore-Test durch ist.

Tutorial

Eine VM auf ihrem Weg, von der Vorbereitung bis zur Abnahme

Dieser Teil folgt einer einzelnen Maschine: was im Gastsystem vor dem Herunterfahren passieren muss, wie der Import läuft, warum Windows danach oft nicht startet und was an Netz und Speicher nachzuziehen ist. Spiel den Ablauf einmal an einer unwichtigen VM komplett durch, danach kannst du ihn in Wellen wiederholen.

01

Das Gastsystem vorbereiten, solange es noch auf ESXi läuft

Fast alles, was nach dem Import schiefgeht, lässt sich vorher im laufenden Gast erledigen. Nach dem Umzug ist derselbe Handgriff eine Reparatur über die Notfallkonsole.

Linux-Gast, vor dem Herunterfahren
# VMware Tools raus, sie greifen sonst weiter in Netz und Dienste ein
sudo systemctl disable --now vmtoolsd
sudo dnf remove -y open-vm-tools      # bzw. sudo apt purge open-vm-tools

# Gast-Agent für Proxmox rein
sudo dnf install -y qemu-guest-agent  # bzw. sudo apt install qemu-guest-agent
sudo systemctl enable qemu-guest-agent

# virtio-Treiber müssen in der initramfs liegen, sonst findet der Kernel
# die Bootplatte nach dem Umzug nicht mehr
sudo dracut --regenerate-all --force  # RHEL, Rocky, AlmaLinux
sudo update-initramfs -u -k all       # Debian, Ubuntu

# Einhängepunkte über UUID statt über /dev/sdX
blkid
grep -v '^#' /etc/fstab

Die initramfs ist der Punkt, an dem Linux-Gäste scheitern. Sie enthält nur die Treiber, die zum Zeitpunkt ihrer Erzeugung gebraucht wurden, und unter ESXi war das kein virtio. Der Neuaufbau vorher kostet eine Minute, hinterher kostet er ein Rettungssystem.

Windows-Gast, vor dem Herunterfahren

  • Das virtio-win-ISO im noch laufenden ESXi-Gast einbinden und die Guest-Tools installieren. Windows nimmt Treiber auch für Hardware entgegen, die noch gar nicht vorhanden ist.
  • VMware Tools deinstallieren und einmal neu starten, bevor du herunterfährst.
  • Feste IP-Adressen notieren, ebenso Lizenzen, die an die MAC-Adresse gebunden sind.
  • Sauber herunterfahren, nicht in den Ruhezustand. Ein Ruhezustandsabbild passt nach dem Wechsel der virtuellen Hardware nicht mehr.
02

Import: zwei Wege, ein Ergebnis

Über ovftool exportieren und importieren
# Auf einer Arbeitsstation mit ovftool, die Quell-VM ist ausgeschaltet
ovftool --noSSLVerify vi://benutzer@esxi01.firma.de/srv-app01 /export/

# Auf dem Proxmox-Knoten
qm importovf 120 /export/srv-app01/srv-app01.ovf local-lvm

# Nur eine einzelne Platte nachziehen
qm importdisk 120 /export/srv-app01_1.vmdk local-lvm

# Controller, Platte und Bootreihenfolge setzen
qm set 120 --scsihw virtio-scsi-single \
  --scsi0 local-lvm:vm-120-disk-0,discard=on,iothread=1
qm set 120 --boot order=scsi0

Rechne beim OVF-Weg mit dem doppelten Platzbedarf, weil der Export zwischengelagert wird. Plane das Exportverzeichnis deshalb auf einen Speicher, der die größte VM einer Welle aufnimmt.

Der zweite Weg: Import direkt aus Proxmox heraus

  • Ab Proxmox VE 8.2 bindest du einen ESXi-Host als Import-Quelle ein, unter Rechenzentrum > Storage > Hinzufügen > ESXi.
  • Der Assistent liest die VM-Liste vom Host, überträgt die Platten und legt die Zielmaschine mit passendem Controller gleich an.
  • Der Zwischenspeicher für das OVF-Archiv entfällt, du brauchst also nicht die doppelte Kapazität.
  • Die Quell-VM muss ausgeschaltet sein. Ein Import im laufenden Betrieb ergibt einen inkonsistenten Stand, auch wenn die Übertragung technisch durchläuft.
03

Wenn Windows nach dem Import hängen bleibt

Der Fehler ist fast immer derselbe: Windows kennt den neuen Speichercontroller nicht und bricht mit INACCESSIBLE_BOOT_DEVICE ab. Es gibt zwei Wege heraus, und beide funktionieren zuverlässig.

Weg A: über einen Controller starten, den Windows kennt
# VM ist aus. Bootplatte vorübergehend an SATA, virtio-ISO dazu
# Erst die vorhandene Platte loesen (--delete entfernt nur die Zuordnung,
# das Abbild bleibt als unbenutzte Disk erhalten)
qm set 120 --delete scsi0
qm set 120 --sata0 local-lvm:vm-120-disk-0
qm set 120 --ide2 local:iso/virtio-win.iso,media=cdrom
qm set 120 --boot order=sata0

# Windows starten, virtio-Treiber im Geräte-Manager installieren,
# danach wieder herunterfahren und zurückstellen
qm set 120 --delete sata0
qm set 120 --scsihw virtio-scsi-single --scsi0 local-lvm:vm-120-disk-0
qm set 120 --boot order=scsi0

Damit Windows den Treiber wirklich installiert und nicht nur bereitlegt, häng vor dem Umstellen eine kleine zweite Platte an virtio-scsi. Windows erkennt neue Hardware, sucht den Treiber auf dem eingebundenen ISO und der Bootvorgang klappt danach auch für die Systemplatte.

Weg B: virt-v2v übernimmt die Treiberarbeit

  • virt-v2v liest die Maschine direkt vom ESXi-Host oder aus einer vmx-Datei und schreibt ein fertiges KVM-Abbild.
  • Bei Windows-Gästen spielt das Werkzeug die virtio-Treiber selbst ein, sofern das Paket virtio-win auf dem Konvertierungsrechner installiert ist.
  • Das Ergebnis legst du als Datei ab und ziehst es mit qm importdisk in den Proxmox-Speicher.
  • Der Weg lohnt sich ab einer zweistelligen Zahl von Windows-Maschinen, weil er sich über ein Skript wiederholen lässt.
04

Netz, MAC-Adressen und Speicheroptionen nachziehen

Die Einstellungen, die nach dem Import fehlen
# MAC-Adresse übernehmen, wenn DHCP-Reservierungen, Lizenzen oder
# Firewallregeln daran hängen. VLAN direkt mitgeben.
qm set 120 --net0 virtio=00:50:56:AA:BB:CC,bridge=vmbr0,tag=42

# Gast-Agent aktivieren, Ballooning bei Datenbanken abschalten
qm set 120 --agent enabled=1,fstrim_cloned_disks=1
qm set 120 --balloon 0

# Platz zurückgeben: discard auf der Platte, TRIM im Gast
qm set 120 --scsi0 local-lvm:vm-120-disk-0,discard=on,ssd=1
# im Gast:
sudo systemctl enable --now fstrim.timer

qm config 120

Ohne discard auf der Platte und fstrim.timer im Gast wächst der belegte Platz auf Thin-Speicher immer weiter, auch wenn im Gast gelöscht wird. Nach einer Migration fällt das besonders auf, weil beim Import einmal jeder Block geschrieben wird.

05

Abnahme und Rückweg

Prüfbefehle nach dem Cutover
qm agent 120 ping
qm agent 120 network-get-interfaces
qm status 120 --verbose

# Erstsicherung sofort, nicht erst im nächsten Zeitfenster
vzdump 120 --storage pbs --mode snapshot \
  --notes-template '{{guestname}} Erstsicherung nach Migration'

qm agent 120 ping ist der schnellste Test, ob der Gast-Agent wirklich antwortet. Solange er das nicht tut, sind Snapshot-Sicherungen nur absturzkonsistent und ein geordnetes Herunterfahren aus der Oberfläche funktioniert nicht.

Vor der Freigabe an die Fachabteilung

  • Alle Platten hängen am geplanten ControllerNach dem Import bleiben einzelne Datenplatten gern auf IDE oder SATA hängen. Das kostet dauerhaft Leistung und fällt erst unter Last auf, wenn niemand mehr an die Migration denkt.
  • Die Erstsicherung wurde einmal zurückgespieltEin vzdump im Zeitplan ist kein Nachweis. Erst die Wiederherstellung in eine Test-VM zeigt, ob Platten, Konfiguration und Netz vollständig erfasst sind.
  • Zeitzone und Zeitsynchronisation stimmenNach einem Umzug laufen die Uhren gern auseinander. Das bricht Kerberos-Anmeldungen, macht Protokolle für die Fehlersuche unbrauchbar und wird selten als Migrationsfolge erkannt.
  • Monitoring und Berechtigungen zeigen auf den neuen ClusterPrüfungen, die noch gegen vCenter laufen, melden weiter grün, während die migrierte Maschine unbeobachtet ist. Dasselbe gilt für Rollen und Zugriffe, die in Proxmox neu vergeben werden müssen.
  • Die alte VM bleibt ausgeschaltet erhalten, mit FristDer Rückweg besteht aus einem Einschalten auf ESXi, solange die Maschine dort noch existiert. Leg einen Termin fest, ab dem gelöscht wird, sonst steht der alte Cluster noch in zwei Jahren und kostet Lizenz und Strom.
Gut zu wissen

Häufige Fragen zu Migration von VMware zu Proxmox

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Kann ich VMs im laufenden Betrieb von ESXi nach Proxmox migrieren?
Nein, ein Live-Umzug zwischen den beiden Plattformen ist nicht vorgesehen. Die VM wird auf dem ESXi-Host heruntergefahren, die Disks werden übertragen und die Maschine startet auf Proxmox VE neu. Die Downtime je VM hängt vor allem von der Disk-Größe und der Netzwerk- beziehungsweise Storage-Geschwindigkeit ab, deshalb lohnt es sich, große Datenlaufwerke getrennt zu behandeln oder vorab zu synchronisieren.
Warum startet meine Windows-VM nach dem Import nicht mehr?
In den allermeisten Fällen fehlt der VirtIO-Speichertreiber. Windows kennt den neuen Controller nicht und bricht mit einem Bluescreen ab. Installiere die virtio-win-Treiber, solange die VM noch auf dem alten Controller läuft, oder hänge nach dem Import eine kleine Zusatzplatte auf VirtIO SCSI an, damit Windows den Treiber lädt, und stelle danach die Systemplatte um. Prüfe zusätzlich, ob die Maschine UEFI verwendet und ob eine EFI-Disk angelegt wurde.
Brauche ich für Proxmox zwingend Ceph?
Nein. Ceph ist sinnvoll, wenn du Shared Storage im Cluster, Live-Migration ohne Kopieren und Ausfallsicherheit ohne externes SAN willst, und es braucht dafür genügend Nodes, OSDs und ein eigenes Netz. Für kleinere Umgebungen sind lokales ZFS mit asynchroner Replikation zwischen zwei oder drei Nodes oder ein vorhandenes NFS- beziehungsweise iSCSI-Storage völlig ausreichend und deutlich einfacher zu betreiben.
Was passiert mit Snapshots, Templates und Backups aus der VMware-Welt?
Snapshots solltest du vor der Migration konsolidieren, denn sie werden nicht übernommen und blähen den Transfer unnötig auf. Templates baust du auf Proxmox VE neu auf, idealerweise über Cloud-Init-fähige Images statt geklonter Altsysteme. Alte VMware-Sicherungen bleiben als Archiv bestehen, sind aber nicht direkt zurückspielbar, deshalb gehört ein vollständiger Backup-Lauf mit Restore-Test auf der neuen Plattform zur Abnahme.
Wie lange dauert so eine Migration realistisch?
Das hängt an der Zahl der VMs, an der Storage-Anbindung und vor allem daran, wie viele Wartungsfenster du bekommst. Der Aufbau von Cluster, Storage, Netzwerk und Backup ist üblicherweise in wenigen Tagen erledigt, der Umzug selbst läuft dann über mehrere Wellen verteilt. Plane den Parallelbetrieb beider Plattformen fest ein, damit du bei Problemen zurückkannst.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.
Rückmeldung aus dem Kurs „Kubernetes Grundkurs“
Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Migration einmal vollständig durchspielen

Im Seminar Migration von VMware zu Proxmox gehst du den kompletten Weg an einer echten Umgebung durch, vom Import über Netzwerk und Storage bis zum Cutover. Wenn dir die Grundlagen zu Proxmox VE noch fehlen, steigst du davor mit dem Proxmox Grundkurs zu KVM, LXC, Storage und Backup ein, für Cluster, Ceph und Hochverfügbarkeit gibt es den Proxmox Aufbaukurs. Alle Kurse laufen wahlweise in Präsenz oder Live-Online, auf Wunsch auch als Inhouse-Termin mit deinem eigenen Migrationsszenario. Melde dich bei uns, dann sortieren wir gemeinsam, welcher Kurs zu deinem Projektstand passt.