WZ-IT Logo
AnleitungProxmox

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

Timo WevelsiepTimo WevelsiepAktualisiert: 09.07.2026

Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.

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:

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:

  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.

Sie möchten Proxmox nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung – DSGVO-konform aus Deutschland.

Häufig gestellte Fragen

Antworten auf die wichtigsten Fragen

Nein. Proxmox importiert VHDX-Dateien direkt: qm disk import erkennt das Format automatisch und schreibt die Disk beim Import in das Format des Ziel-Storage (z. B. RAW auf ZFS/LVM-Thin oder QCOW2 auf Verzeichnis-Storage). Ein manueller Umweg über qemu-img convert ist nur bei defekten oder exotischen Images nötig.

Die zwei häufigsten Ursachen: Erstens fehlende VirtIO-Treiber - hängen Sie die Disk zunächst als SATA oder IDE an, installieren Sie die Treiber und stellen Sie erst dann auf VirtIO SCSI um. Zweitens der falsche Firmware-Typ: Eine Gen2-VM (UEFI) braucht OVMF mit EFI-Disk, eine Gen1-VM SeaBIOS. Stimmt der Typ nicht mit der Quelle überein, findet Windows den Bootloader nicht.

Checkpoints (AVHDX-Differenzdateien) müssen vor der Migration zusammengeführt werden: alle Checkpoints im Hyper-V-Manager löschen und warten, bis der Merge abgeschlossen ist. Erst dann liegt der komplette Datenstand in der VHDX-Basisdatei. Eine AVHDX-Kette lässt sich nicht sinnvoll importieren.

In Proxmox die VM mit OVMF (UEFI) und EFI-Disk mit vorregistrierten Schlüsseln anlegen (Maschinentyp q35 empfohlen), dazu ein TPM-State-Volume (TPM 2.0) hinzufügen. Wichtig bei BitLocker: vor der Migration die Verschlüsselung pausieren oder den Recovery-Key bereithalten, da sich die Plattform-Messwerte ändern und BitLocker sonst die Wiederherstellung verlangt.

Nein. Der GUI-Import-Assistent von Proxmox unterstützt ESXi als Quelle (seit PVE 8.2) sowie OVA/OVF-Dateien (seit PVE 8.3) - Hyper-V gehört nicht dazu. Der offizielle Weg für Hyper-V ist der Disk-Import per qm disk import, wie in dieser Anleitung beschrieben: Die VHDX wird direkt gelesen, nur die VM-Konfiguration wird manuell nachgebildet.

AVMA (Automatic Virtual Machine Activation) funktioniert nur mit einem Hyper-V-Datacenter-Host und entfällt auf Proxmox. VMs, die bisher per AVMA aktiviert waren, brauchen einen KMS-Server, Active-Directory-basierte Aktivierung oder MAK-Schlüssel. Auch die Lizenzseite ändert sich nicht: Windows Server wird auf Proxmox nach denselben Core-Regeln lizenziert wie auf Hyper-V.

Nein, eine Live-Migration zwischen Hyper-V und Proxmox gibt es nicht - die VM muss für Kopie und Import heruntergefahren sein. Die Downtime pro VM besteht aus Herunterfahren, VHDX-Transfer und erstem Boot; bei großen Disks lässt sie sich mit einem Zwischen-Sync (z. B. rsync der VHDX auf den Zielhost vorab, finaler Delta-Sync nach dem Shutdown) deutlich verkürzen.

Lassen Sie uns über Ihre Idee sprechen

Ob konkrete IT-Herausforderung oder einfach eine Idee - wir freuen uns auf den Austausch. In einem kurzen Gespräch prüfen wir gemeinsam, ob und wie Ihr Projekt zu WZ-IT passt.

E-Mail
[email protected]

Führende Unternehmen vertrauen WZ-IT

  • Rekorder
  • Keymate
  • Führerscheinmacher
  • SolidProof
  • ARGE
  • Boese VA
  • nextGYM
  • Maho Management
  • Golem.de
  • Millenium
  • Paritel
  • Yonju
  • EVADXB
  • Mr. Clipart
  • Aphy
  • Negosh
  • ABCO Water Systems
Timo Wevelsiep & Robin Zins - CEOs of WZ-IT

Timo Wevelsiep & Robin Zins

Geschäftsführer

1/3 - Themenauswahl33%

Worum geht es bei Ihrer Anfrage?

Wählen Sie einen oder mehrere Bereiche, bei denen wir Sie unterstützen dürfen.