Hyper-V → Proxmox: Migration ohne Datenverlust

VMware ist 2024 zu Broadcom gewechselt — und in der Folge sind viele Mittelstandskunden auf Proxmox umgestiegen. Was viele übersehen: Auch Hyper-V-Bestände wandern verstärkt zu Proxmox. Die Gründe sind unterschiedlich — Lizenzkosten der Microsoft-Datacenter-Edition, Wunsch nach einheitlicher Hypervisor-Plattform statt Mischbetrieb, Konsolidierung kleinerer Hyper-V-Hosts auf einen Proxmox-Cluster — aber die Migration läuft technisch nach den gleichen Grundprinzipien.

Dieser Artikel zeigt die Schritte konkret. Wer den umgekehrten Weg von VMware kommt, findet bei uns ebenfalls Praxismaterial: Proxmox-VMware-Migration: Praxisbeispiel und Von VMware zu Proxmox: der Umstieg.

Vorbereitung im Gast-OS — vor dem Umzug

Der entscheidende Punkt: Was im Gast-OS getan werden muss, sollte solange getan werden, wie die VM noch unter Hyper-V läuft. Nach dem Umzug ist es deutlich aufwändiger.

Bei Windows-VMs:

1. Hyper-V-Integration-Services / Guest-Services entfernen. Über Programme & Features deinstallieren. Diese Komponenten erwarten Hyper-V-spezifische Schnittstellen und führen unter KVM/QEMU zu Bluescreens oder Performance-Problemen.
2. VirtIO-Treiber vorinstallieren. Das ist der wichtigste Schritt. Das aktuelle VirtIO-ISO von Fedora People (virtio-win) herunterladen, in der noch laufenden VM mounten und alle Treiber installieren (Storage, Netzwerk, Balloon, Serial). Wenn dieser Schritt vergessen wird, bootet Windows nach der Migration nicht — weil es keinen Treiber für die neue VirtIO-SCSI-Disk findet.
3. BitLocker prüfen. Wenn aktiv, vor der Migration entschlüsseln oder den Recovery-Key griffbereit haben.
4. MAC-Adresse notieren. Lizenz-Aktivierungen sind oft an MAC-Adresse oder Hardware-ID gebunden.

Bei Linux-VMs:

1. Hyper-V-spezifische Module prüfen. lsmod | grep hv_ zeigt geladene Hyper-V-Module. Diese sind unter Proxmox ohne Funktion, schaden aber meist nicht — moderne Kernels laden je nach Hypervisor die passenden Treiber.
2. fstab auf UUIDs umstellen. Wenn /dev/sda1 verwendet wird statt UUID, kann das nach Umzug auf VirtIO-SCSI zu Boot-Problemen führen (/dev/vda1). UUIDs sind robust.
3. Initramfs neu bauen. Auf modernen Distributionen einmal update-initramfs -u (Debian/Ubuntu) bzw. dracut -f (Rocky/RHEL/CentOS) ausführen, damit die VirtIO-Module im Initramfs landen.

VHDX nach QCOW2 konvertieren

Hyper-V verwendet VHDX (oder älter VHD). Proxmox arbeitet bevorzugt mit QCOW2 oder Raw — beide sind native QEMU-Formate. Die Konvertierung läuft mit qemu-img:

# Auf einem Linux-System mit qemu-utils:
qemu-img convert -p -O qcow2 /pfad/zur/vm.vhdx /pfad/output.qcow2

# Alternativ Raw (etwas schneller, mehr Platzbedarf):
qemu-img convert -p -O raw /pfad/zur/vm.vhdx /pfad/output.raw

Der -p-Schalter zeigt einen Fortschrittsbalken — bei großen VHDX-Files (mehrere hundert GB) hilfreich.

Wichtige Punkte:

• VHDX dynamic wird automatisch entpackt. QCOW2 ist ebenfalls dynamisch (thin-provisioned).
• Snapshots, die in der VHDX-Kette liegen (.avhdx-Dateien), müssen vorher gemergt werden — entweder in Hyper-V über “Checkpoints löschen” oder mit qemu-img rebase.
• Quelldatei nicht löschen, bevor die neue VM erfolgreich gestartet ist.

Import in Proxmox

Es gibt drei pragmatische Wege, eine QCOW2/Raw-Disk in eine Proxmox-VM zu bekommen:

Variante 1 — qm importdisk (empfohlen). Zuerst eine leere VM in Proxmox anlegen (passende CPU, RAM, kein Storage). VM-ID notieren, z.B. 101. Dann auf dem Proxmox-Host:

qm importdisk 101 /pfad/output.qcow2 local-lvm --format qcow2

Die Disk wird in den Storage-Pool importiert und ist anschließend als nicht-zugewiesene Disk in der VM 101 sichtbar. In der GUI über “Hardware → Disk → Hinzufügen” der VM zuordnen.

Variante 2 — manuell kopieren. Datei direkt in /var/lib/vz/images/101/ legen und in der VM-Konfig (/etc/pve/qemu-server/101.conf) referenzieren. Funktioniert, ist aber fehleranfälliger.

Variante 3 — Proxmox VE Migration Tool. Proxmox liefert seit Version 8.2 ein proxmox-vm-migrate-Skript, das Quell-Hypervisor ansprechen und die Disks live übertragen kann. Für VMware getestet, für Hyper-V experimentell — wir empfehlen weiterhin den manuellen Export-Konvertieren-Import-Weg.

Boot-Modus: BIOS vs. UEFI, Generation 1 vs. 2

Ein Stolperstein, der Migrations-Anfänger oft kostet: Hyper-V hat Generation 1 (BIOS) und Generation 2 (UEFI).

• Generation 1 → SeaBIOS in Proxmox. Default und unkompliziert.
• Generation 2 → OVMF (UEFI) in Proxmox. Erfordert separates EFI-Disk-Volumen in der VM-Konfig (efidisk0: local-lvm:vm-101-disk-1,size=4M).

Wenn das EFI-Disk vergessen wird, bootet die VM nicht. In der Proxmox-GUI vor dem ersten Start unter “Hardware” das EFI-Disk hinzufügen.

Bei Generation-2-VMs mit Windows muss zusätzlich die Secure-Boot-Konfiguration beachtet werden. Wir empfehlen, Secure Boot bei der Migration zunächst zu deaktivieren — sobald die VM stabil läuft, kann es wieder aktiviert werden.

VirtIO statt IDE / SATA — der Performance-Punkt

In der neu erstellten Proxmox-VM ist die importierte Disk standardmäßig oft als SCSI mit dem lsi-Controller eingerichtet. Für maximale Performance umstellen auf:

• SCSI-Controller: VirtIO SCSI single
• Disk-Bus: SCSI mit VirtIO-Treiber
• Netzwerk: VirtIO (paravirtualisiert)

Wichtig: Die VirtIO-Treiber müssen im Gast-OS vorhanden sein, bevor die Umstellung erfolgt. Genau deshalb war Schritt 2 der Vorbereitung (VirtIO-Treiber vorinstallieren) so wichtig.

Wenn vergessen wurde: zuerst mit IDE-Disk booten, dann im laufenden Gast die VirtIO-Treiber nachinstallieren, dann VM herunterfahren und Disk-Bus auf VirtIO SCSI umstellen.

Netzwerk und MAC-Adressen

Die VM bekommt in Proxmox standardmäßig eine neue MAC-Adresse. Das kann zu zwei Problemen führen:

1. DHCP-Reservierungen / Inventar. Wenn der DHCP-Server für die VM eine reservierte IP per MAC vergibt, ändert sich nach Migration die IP. Lösung: In Proxmox die alte MAC-Adresse manuell setzen (in der VM-Hardware unter “Network Device → Advanced”).

2. Software-Lizenz-Aktivierung. Manche Software (insbesondere ältere Windows-Server-Editionen, Datenbank-Lizenzen, CAD-Software) ist an MAC-Adresse oder Hardware-ID gebunden. Bei Microsoft Windows hilft meist eine erneute Aktivierung über Telefon-Aktivierung; bei spezialisierter Software vorher mit dem Hersteller klären.

Test-VM zuerst — Produktivsystem im Wartungsfenster

Die wichtigste organisatorische Empfehlung: Migration einer Test- oder Staging-VM zuerst durchführen, vollständig durchlaufen, dokumentieren — und dann erst Produktivsysteme im Wartungsfenster anpacken.

Typischer Ablauf für eine Produktiv-VM:

1. Wartungsfenster vereinbaren (häufig Wochenende, abends).
2. VM in Hyper-V herunterfahren (graceful shutdown, nicht hart).
3. VHDX kopieren auf das Migrations-System (NFS-Share, externe USB-3-Disk, schnelles Netzwerk).
4. Konvertieren mit qemu-img.
5. Importieren in Proxmox.
6. Hardware in der VM-Konfig anpassen (Disk-Bus, Netzwerk, EFI bei Gen 2).
7. Erstmal-Start und Boot-Verhalten beobachten — Console öffnen, nicht nur Pings.
8. Lizenz-Aktivierung, Anwendungs-Funktionstest, Backups einrichten.
9. Erst nach erfolgreichem Smoke-Test: Hyper-V-Quelle aufräumen (VHDX archivieren, VM in Hyper-V löschen).

Faustregel: Pro Produktiv-VM 30-60 Minuten reines Wartungsfenster einplanen, plus 30 Minuten Puffer. Bei größeren VMs (>500 GB) länger.

Cluster-Aspekte und Live-Replikation

Wenn Proxmox bereits als Cluster aufgesetzt ist, kann die importierte VM nach erfolgreichem Boot in einen HA-Verbund aufgenommen werden. Wer einen größeren Hyper-V-Bestand schrittweise migriert, profitiert von einem 3-Node-Proxmox-Cluster mit Shared Storage — siehe Proxmox-Cluster mit drei Nodes und Shared Storage.

Eine echte Live-Migration von Hyper-V zu Proxmox (ohne Downtime) ist mit Bordmitteln nicht möglich — beide Hypervisoren sprechen unterschiedliche Memory-Page-Protokolle. Wer Downtime minimieren will, kann mit Datenbank- oder Storage-Replikation auf Applikations-Ebene arbeiten und den finalen Cutover dann auf Sekunden begrenzen.

Fazit

Hyper-V-zu-Proxmox-Migration ist 2026 ein eingespielter Workflow: VHDX in QCOW2 konvertieren, in Proxmox importieren, Hardware-Profile anpassen, VirtIO-Treiber sicherstellen. Der häufigste Fehler ist nicht die Konvertierung selbst, sondern die fehlende Vorbereitung im Gast-OS — Hyper-V-Integration-Services entfernen und VirtIO-Treiber vor der Migration installieren spart später Stunden Fehlersuche.

Für KMU mit fünf bis dreißig Hyper-V-VMs ist die Migration in einem Wochenend-Wartungsfenster zu schaffen. Für größere Umgebungen empfiehlt sich ein gestaffeltes Vorgehen über mehrere Wochenenden, mit Test-VM-Validierung am Anfang. DATAZONE übernimmt die Migration komplett — von der Inventur über die Konvertierung bis zur Cluster-Übernahme im laufenden Betrieb.