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:
- 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.
- BitLocker pausieren (falls aktiv):
Suspend-BitLocker -MountPoint "C:" -RebootCount 0- ohne-RebootCount 0reaktiviert sich der Schutz nach dem ersten Neustart wieder, der Default ist 1. Den Recovery-Key sichern: Nach dem Plattformwechsel ändern sich die TPM-Messwerte. - 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.
- 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:
| Hyper-V | Proxmox-Einstellung |
|---|---|
| Generation 1 (BIOS) | Firmware SeaBIOS, Maschinentyp i440fx |
| Generation 2 (UEFI) | Firmware OVMF (UEFI), EFI-Disk hinzufügen, Maschinentyp q35 empfohlen |
| Gen2 mit Secure Boot | OVMF mit vorregistrierten Schlüsseln (Standard beim Anlegen der EFI-Disk) |
| vTPM (Windows 11 / Server 2025) | TPM-State-Volume hinzufügen, Version 2.0 |
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:
- VM mit der Boot-Disk an SATA starten - damit bootet Windows ohne Zusatztreiber.
- Die aktuelle virtio-win-ISO (Download bei Fedora) als CD-Laufwerk einhängen und
virtio-win-guest-tools.exeausfü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.msiallein enthält nur die Treiber, nicht den Agent. - 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. - 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. - 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.
