Hyper-V zu Proxmox migrieren: Schritt für Schritt mit VHDX-Import

Sie möchten nicht nur einzelne VMs importieren, sondern eine vollständige Hyper-V-Umgebung belastbar ablösen? Der Virtualisierungs-Exit-Check liefert Bestandsaufnahme, Proxmox-Zielbild, Migrationswellen und einen belastbaren Umsetzungsrahmen zum Festpreis. Exit-Check ansehen · Hyper-V-Migration durch WZ-IT

Der Umzug einer VM von Microsoft Hyper-V zu Proxmox VE ist technisch unspektakulärer, als viele erwarten: Proxmox importiert VHDX-Dateien direkt, ohne Konvertierung. Die eigentlichen Stolpersteine sind die VirtIO-Treiber, der richtige Firmware-Typ (Gen1 vs. Gen2) und die Windows-Aktivierung. Diese Anleitung führt durch alle sechs Schritte (Stand Juli 2026, Proxmox VE 9.x - die Befehle gelten auch für 8.x).

Warum Unternehmen gerade jetzt wechseln (Hyper-V Server 2019 war die letzte kostenlose Version, Windows Server 2025 lizenziert pro Core) und wie eine geplante Migration ganzer Umgebungen abläuft, behandelt unsere Service-Seite Hyper-V zu Proxmox Migration - dieser Guide konzentriert sich auf die Technik.

Schritt 1: VM vorbereiten und herunterfahren

Vor dem Umzug in Hyper-V:

1. Checkpoints zusammenführen: Alle Checkpoints der VM im Hyper-V-Manager löschen und warten, bis Hyper-V die AVHDX-Differenzdateien in die Basis-VHDX gemergt hat. Eine Checkpoint-Kette lässt sich nicht importieren.
2. BitLocker pausieren (falls aktiv): Suspend-BitLocker -MountPoint "C:" -RebootCount 0 - ohne -RebootCount 0 reaktiviert sich der Schutz nach dem ersten Neustart wieder, der Default ist 1. Den Recovery-Key sichern: Nach dem Plattformwechsel ändern sich die TPM-Messwerte.
3. Konfiguration notieren: Generation (1 = BIOS, 2 = UEFI), Anzahl vCPUs, RAM, statische IP-Adressen, VLAN-Zuordnung. Die MAC-Adresse ändert sich beim Umzug - Windows behandelt die neue NIC als neues Gerät.
4. Sauber herunterfahren (kein Speichern des Zustands, kein Pausieren).

Optional, aber bewährt: Die VirtIO-Treiber schon unter Hyper-V vorinstallieren (virtio-win-ISO mounten, Installer durchlaufen lassen). Dann bootet Windows nach dem Import auch direkt von einer VirtIO-Disk, und Schritt 5 verkürzt sich auf die Kontrolle.

Schritt 2: VHDX auf den Proxmox-Host übertragen

Ein formeller Export über den Hyper-V-Manager ist nur nötig, wenn Sie keinen direkten Zugriff auf die VHDX-Dateien haben - die Disk-Dateien selbst genügen. Übertragungswege:

• SMB-Freigabe vom Hyper-V-Host, auf dem Proxmox-Host mounten: mount -t cifs //hyperv-host/freigabe /mnt/hyperv -o username=admin
• SCP/rsync von einer Zwischenstation: rsync -avP disk.vhdx root@pve:/var/lib/vz/import/
• Bei sehr großen Disks: Vorab-Sync im laufenden Betrieb und finaler Delta-Sync nach dem Shutdown - das drückt die Downtime auf Minuten.

Sowohl dynamische als auch feste VHDX werden unterstützt; auch VHD (das ältere Format) importiert Proxmox direkt.

Schritt 3: Ziel-VM in Proxmox anlegen

Die VM zunächst ohne Festplatte anlegen (im Wizard „Do not use any media", die vorgeschlagene Disk entfernen). Entscheidend ist die Abbildung der Hyper-V-Generation:

Weitere Empfehlungen: OS-Typ passend setzen (qm set 201 --ostype win11 gilt für Windows 11, Server 2022 und 2025), CPU-Typ host (oder x86-64-v2-AES in gemischten Clustern für Live-Migration), SCSI-Controller VirtIO SCSI single, Netzwerkkarte VirtIO.

Schritt 4: VHDX mit qm disk import importieren

Der Kern der Migration ist ein einziger Befehl auf dem Proxmox-Host:

qm disk import 201 /mnt/hyperv/disk.vhdx local-zfs

201 ist die VM-ID, local-zfs das Ziel-Storage. Proxmox erkennt das VHDX-Format automatisch und konvertiert beim Import in das Format des Ziel-Storage (RAW auf ZFS/LVM-Thin, wahlweise QCOW2 auf Verzeichnis-Storage mit --format qcow2). Ein manueller qemu-img convert-Zwischenschritt ist nicht nötig.

Danach die importierte Disk anhängen und bootfähig machen:

# Disk erscheint als "unused0" - anhängen (erster Boot bewusst über SATA, siehe Schritt 5):
qm set 201 --sata0 local-zfs:vm-201-disk-1
# Boot-Reihenfolge setzen:
qm set 201 --boot order=sata0

Bei mehreren VHDX-Dateien den Import je Disk wiederholen; Daten-Disks können direkt als VirtIO SCSI angehängt werden - nur die Boot-Disk braucht den SATA-Umweg.

Schritt 5: VirtIO-Treiber installieren und auf VirtIO umstellen

Windows bringt keine VirtIO-Treiber mit - eine direkt an VirtIO SCSI gehängte Boot-Disk endet ohne vorinstallierte Treiber im Bluescreen INACCESSIBLE_BOOT_DEVICE. Der stabile Weg:

1. VM mit der Boot-Disk an SATA starten - damit bootet Windows ohne Zusatztreiber.
2. Die aktuelle virtio-win-ISO (Download bei Fedora) als CD-Laufwerk einhängen und virtio-win-guest-tools.exe ausführen - das Bundle installiert Storage- (viostor/vioscsi), Netzwerk- (NetKVM) und Balloon-Treiber plus den QEMU Guest Agent in einem Durchgang. Achtung: virtio-win-gt-x64.msi allein enthält nur die Treiber, nicht den Agent.
3. Den Guest Agent in den VM-Optionen aktivieren (qm set 201 --agent 1) - er ersetzt die Hyper-V-Integrationsdienste für Shutdown, IP-Anzeige und konsistente Backups.
4. Herunterfahren, Boot-Disk von SATA auf VirtIO SCSI umhängen (qm set 201 --scsi0 ... --boot order=scsi0, den SATA-Eintrag entfernen), Netzwerkkarte auf VirtIO prüfen.
5. Neu starten - Windows bindet die Treiber und läuft mit voller I/O-Performance.

Alternative aus dem Proxmox-Wiki: statt des SATA-Umwegs eine kleine Dummy-Disk (1-2 GB) zusätzlich an VirtIO SCSI hängen, booten, die Treiberbindung abwarten, dann die Boot-Disk umhängen und die Dummy-Disk entfernen.

Die Hyper-V-Integrationsdienste sind seit Windows Server 2016 Teil des Betriebssystems und müssen nicht deinstalliert werden; sie bleiben schlicht inaktiv. Linux-Gäste brauchen den Umweg nicht: VirtIO-Treiber sind im Kernel enthalten, die Disk kann direkt an VirtIO SCSI - nur /etc/fstab und Bootloader auf Gerätenamen-Änderungen prüfen, den qemu-guest-agent nachinstallieren und bei Hyper-V-optimierten Images sicherstellen, dass die virtio-Module im initramfs stecken.

Schritt 6: Testen und aktivieren

• Netzwerk: Die NIC erscheint mit neuer MAC als neues Gerät - statische IPs neu setzen, danach die alte, versteckte NIC im Geräte-Manager entfernen. VLAN-Tags setzt Proxmox an der Bridge oder direkt an der VM-NIC.
• Funktionstest: Dienste, Anwendungen, Freigaben, Domänen-Anbindung - erst nach erfolgreichem Test die Quell-VM in Hyper-V löschen. Bis dahin bleibt sie das Rollback.
• Aktivierung: AVMA setzt einen Hyper-V-Datacenter-Host voraus und funktioniert auf Proxmox nicht - bisher AVMA-aktivierte VMs auf KMS, AD-basierte Aktivierung oder MAK umstellen. Die Lizenzregeln (Core-Minima, Standard vs. Datacenter, Cluster-Frage) behandelt ausführlich Windows Server auf Proxmox lizenzieren.
• Monitoring und Backup: Die neue VM in die Backup-Jobs (idealerweise mit Proxmox Backup Server) und ins Monitoring aufnehmen.

Wann der Selbstbau-Weg an Grenzen stößt

Für eine Handvoll VMs ist dieser Weg gut selbst machbar. Aufwändiger wird es bei Dutzenden VMs mit Abhängigkeiten, Failover-Cluster-Umgebungen mit Cluster Shared Volumes, engen Wartungsfenstern oder Domänencontrollern und Datenbank-Servern, bei denen die Reihenfolge zählt. Für solche Projekte planen und übernehmen wir die Migration End-to-End - mit Inventur, Testmigration, Cutover-Plan und Betrieb danach: Hyper-V zu Proxmox Migration, anschließend auf Wunsch als Managed Proxmox ab 179,90 Euro pro Node und Monat. Fragen dazu klären wir gern im kostenlosen Erstgespräch.