How to Migrate a Virtual Machine from Hyper-V to Proxmox VE (VHDX to qcow2, Step by Step)

If you've got a Windows Server box running Hyper-V and you're eyeing Proxmox VE as the replacement, the hardest part isn't installing Proxmox. It's getting your existing VMs across without rebuilding them from scratch. Hyper-V stores disks in VHDX format, Proxmox wants qcow2 or raw, and there's no "Import from Hyper-V" button anywhere in the Proxmox interface. You're doing this by hand.

The good news: it's a well-worn path. You export the disk, convert it, attach it to a new VM shell, and fix a couple of Windows-specific quirks that trip people up on the first boot. None of it is exotic — it's mostly qemu-img and qm, two tools that ship with every Proxmox VE install. I'll walk through the whole thing, including the two mistakes that account for most of the "my migrated VM won't boot" posts on the Proxmox forum.

What You Will Learn

• Why Hyper-V and Proxmox VE use different disk formats, and what that means for you
• How to tell if your VM is Hyper-V "Generation 1" or "Generation 2" — this decides which Proxmox BIOS setting you need
• How to get the VHDX file off the Hyper-V host and onto Proxmox
• How to convert VHDX to qcow2 with qemu-img convert
• How to build a matching empty VM in Proxmox and import the converted disk
• Why a freshly migrated Windows VM often blue-screens on first boot, and how to avoid it
• How to install VirtIO drivers so the VM gets proper disk and network performance instead of slow emulated hardware

What Is This Feature?

Hyper-V is Microsoft's hypervisor, built into Windows Server and available on Windows 10/11 Pro as an optional feature. It stores each virtual disk as a VHDX file — a format Microsoft designed for its own stack. Proxmox VE runs on QEMU/KVM instead, and QEMU doesn't read VHDX natively for anything beyond a one-time conversion. It wants qcow2 (a flexible, snapshot-capable format) or raw (a plain byte-for-byte disk image, no extra features, slightly faster).

Migrating a VM, in practice, means converting the disk format and rebuilding the VM's configuration around it — CPU count, RAM, network adapter, boot mode — because none of that metadata comes across automatically. Proxmox has no idea what a Hyper-V VM's settings were. You're recreating them.

One more thing worth explaining up front: VirtIO. It's a set of paravirtualized drivers — meaning the guest OS talks almost directly to the virtualization layer instead of going through slow, fully emulated hardware. A Windows VM running on emulated SATA and an emulated Intel NIC works, but a Windows VM running VirtIO disk and VirtIO network drivers is noticeably faster, especially for disk I/O. Hyper-V VMs never had VirtIO drivers installed, because Hyper-V doesn't use them — so installing them is part of this migration, not optional.

Why Would You Use It?

Most people doing this aren't switching hypervisors for fun. The usual reasons: Windows Server licensing costs are adding up for a homelab or small business that doesn't need Active Directory or Hyper-V's clustering features, an old Hyper-V host is due for replacement and it's a natural point to switch platforms, or someone just wants one hypervisor across their whole environment instead of running Proxmox for Linux VMs and Hyper-V for a couple of Windows ones.

Whatever the reason, the VM itself — the OS install, the applications, the data — doesn't need to change. You're moving the disk, not reinstalling Windows.

Prerequisites

• A working Proxmox VE 8.x or 9.x host with enough free storage to hold the converted disk — plan for roughly the same size as the source VHDX, sometimes a bit more
• Admin access to the Hyper-V host through Hyper-V Manager
• The VM shut down normally in Windows (not "Saved State" — a saved-state VM has memory contents tied to the disk snapshot and Hyper-V won't let you touch the VHDX cleanly until it's fully off)
• A way to move a large file off the Hyper-V host: an SMB share, SCP/WinSCP, or even an external USB drive if the network is slow
• The VirtIO driver ISO for Windows, downloaded ahead of time (the current stable build is hosted by the Fedora Project's virtio-win project, and it's the same ISO Proxmox's own Windows guest documentation links to)
• SSH or console access to the Proxmox host

Step-by-Step Tutorial

Step 1: Shut down the VM and note whether it's Generation 1 or 2

In Hyper-V Manager, right-click the VM and choose Shut Down (not Save, not Turn Off if you can avoid it — a hard power-off risks a dirty filesystem). While it's off, open Settings and check the top of the window. It'll say Generation 1 or Generation 2.

This matters more than people expect. Generation 1 VMs boot the old way, with a legacy BIOS and an MBR partition table. Generation 2 VMs boot with UEFI and a GPT partition table — the modern default for Windows Server 2016 and later, and for Windows 11. You need to match this in Proxmox or the disk won't boot at all.

Step 2: Find the VHDX file

Still in Settings, click Hard Drive under the SCSI or IDE controller. The full path is listed there — usually something like C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Hard Disks\ServerName.vhdx.

Step 3: Copy the VHDX to your Proxmox host

Set up a temporary SMB share on the Proxmox host, or push the file over with WinSCP from the Windows side. Either way, land it somewhere with room to spare — /var/lib/vz/template/iso/ or a scratch directory on your biggest storage volume works fine as a staging spot. A 100 GB VHDX takes a while over gigabit Ethernet, so if you've got a lot of VMs to move, budget real time for this part.

Step 4: Convert VHDX to qcow2

On the Proxmox host, run:

qemu-img convert -p -O qcow2 /path/to/ServerName.vhdx /path/to/ServerName.qcow2

qemu-img auto-detects the VHDX source format, so you don't need to specify -f vhdx unless you want to be explicit. The -p flag shows a progress bar, which you'll want — this can take several minutes on a large disk. Dynamically-expanding VHDX files convert fine directly; you don't need to convert them to fixed-size first.

Step 5: Create an empty VM shell in Proxmox

In the Proxmox web interface, click Create VM. Give it a name and matching VMID, then work through the wizard:

• On the OS tab, select "Do not use any media" — you're not installing from an ISO
• On the System tab: if the source was Generation 2, set BIOS to OVMF (UEFI) and add an EFI disk when prompted. If it was Generation 1, leave BIOS as SeaBIOS
• On the Disks tab, delete the default disk Proxmox creates — you'll attach the imported one instead
• Set CPU cores and RAM to roughly match what the VM had under Hyper-V (check the old Settings window if you didn't note it down)
• On the Network tab, leave the model as VirtIO — you'll install the driver for it in a later step

Finish the wizard without starting the VM.

Step 6: Import the converted disk

Back at the shell, run:

qm importdisk <vmid> /path/to/ServerName.qcow2 <storage-name> --format qcow2

Replace <vmid> with the ID you just created and <storage-name> with wherever you want the disk to live (local-lvm, a ZFS pool, whatever storage you've configured). This copies the disk into Proxmox's storage and attaches it to the VM as an unused disk — it won't show up as a bootable drive yet.

Step 7: Attach the disk — as SATA, for now

In the VM's Hardware tab, double-click Unused Disk 0 and add it. Here's the part people get wrong: attach it as SATA, not VirtIO SCSI, for the first boot. Windows has no idea what a VirtIO SCSI controller is yet, and if it can't see the boot disk, it can't boot. SATA is emulated hardware Windows already has drivers for built in.

While you're in there, also attach the VirtIO driver ISO you downloaded earlier as a second CD/DVD drive. Then go to Options → Boot Order and make sure the SATA disk is first.

Step 8: Boot it and install VirtIO drivers

Start the VM and open the console. It should boot into Windows normally, running on emulated hardware — a bit sluggish, but working. Once you're logged in, open File Explorer, find the VirtIO ISO's drive letter, and run virtio-win-gui-installer.exe. Install everything, or at minimum the disk (viostor/vioscsi) and network (NetKVM) drivers. Reboot when it asks.

Step 9: Switch to VirtIO SCSI and reboot

Shut the VM down cleanly from inside Windows. Back in the Proxmox hardware tab, remove the SATA disk entry (not delete the disk — just detach it) and re-add it as SCSI, with the SCSI controller type set to VirtIO SCSI single under the Options tab. Update boot order to put this SCSI disk first. Start the VM again — since you already installed the vioscsi driver in Step 8, Windows recognizes the controller and boots straight through.

Commands Explained

Common Errors

• INACCESSIBLE_BOOT_DEVICE blue screen right after import. You attached the disk as VirtIO SCSI before Windows had the VirtIO driver installed. Go back, attach as SATA, boot, install drivers, then switch.
• Black screen, VM just sits there, no boot menu. Almost always a BIOS mismatch — you set SeaBIOS for a Generation 2 (UEFI) source VM, or forgot to add an EFI disk when using OVMF. Check which generation the source was and match it.
• "qemu-img: Could not open... Permission denied" during conversion. The VHDX is still marked in-use, usually because the Hyper-V VM wasn't fully shut down, or you copied the file while Hyper-V still had a snapshot/checkpoint referencing it. Delete any checkpoints in Hyper-V Manager and confirm the VM shows "Off," not "Saved," before copying.
• Network adapter missing after boot. Same root cause as the boot-device error — no NetKVM driver installed yet. It'll show up as an "Unknown device" in Device Manager until you run the VirtIO installer.
• Disk import finishes but the VM shows a much smaller usable disk than expected. This is usually a partition table issue, not a Proxmox problem — check inside Windows Disk Management; the partition may need to be extended to use the full disk with diskpart or the Disk Management GUI.

Troubleshooting

If the VM boots but feels slow even after installing VirtIO drivers, open Device Manager and check for anything under "Other devices" with a yellow warning icon — that's a device the VirtIO installer didn't cover (the balloon driver or QEMU guest agent service, usually). Installing the full VirtIO package rather than picking individual drivers avoids this.

If qm importdisk fails partway through with a storage error, check free space on the target storage first — a half-copied disk import is almost always running out of room, not a format problem. ZFS and LVM-thin pools can look like they have space free at the pool level while a specific dataset or volume group is tight.

Activation is worth mentioning separately: Windows sometimes flags a hardware change this significant and drops to an unactivated state, particularly with volume-licensed Windows Server images tied to a specific Hyper-V host via KMS. If that happens, running slmgr /ato from an elevated command prompt after confirming network connectivity usually reactivates it against your KMS server or Microsoft's activation servers.

Best Practices

• Take a Hyper-V checkpoint before you start, even though you're shutting the VM down anyway — it costs nothing and gives you a rollback path if the migration goes sideways.
• Convert one VM first as a test run before doing a whole fleet. The Generation 1 vs 2 distinction and the SATA-then-VirtIO dance are easy to get wrong the first time and easy to repeat correctly once you've done it.
• Don't delete the original VHDX or the Hyper-V VM until you've confirmed the Proxmox VM boots, has network access, and Windows is activated. Keep it around for at least a week.
• Install the QEMU Guest Agent inside the migrated VM once it's stable — it's included in the same VirtIO ISO and lets Proxmox request clean shutdowns and report the VM's actual IP address in the GUI.
• If the VM has multiple disks, repeat the import/attach process for each VHDX separately. They don't need to go through the SATA-first dance individually — only the boot disk does, since that's the one Windows needs a working driver for before it can even start loading.

Frequently Asked Questions

Can I convert straight to raw instead of qcow2?

Yes — swap -O qcow2 for -O raw in the conversion command. Raw is marginally faster with no format overhead, but you lose qcow2's snapshot support in Proxmox. Most people keep qcow2 unless they're on ZFS storage, where Proxmox handles snapshots at the filesystem level anyway and raw is the more common choice.

Do I need to shut the source VM down, or can I convert a running one?

Shut it down. Converting a VHDX that's still attached to a running Hyper-V VM risks copying a file mid-write, and Hyper-V will often lock the file anyway, causing the permission error covered above.

What about Linux VMs running on Hyper-V?

Same process, minus the VirtIO driver installation step for the OS itself — most modern Linux kernels already have VirtIO drivers built in, so a Linux guest just boots straight onto VirtIO SCSI and VirtIO net without the SATA detour Windows needs.

How long does this actually take?

For a 60-80 GB Windows Server VM over a gigabit connection, figure 20-30 minutes for the file copy, 10-15 minutes for the conversion, and another 15 minutes for the driver install and reboot cycle. An hour per VM, roughly, once you've done it once and know where the pitfalls are.

Is there a way to skip the manual disk import and use an ESXi-style import wizard?

No — Proxmox VE's built-in Import Wizard only talks to a live VMware ESXi or vCenter connection over the network. There's no equivalent for Hyper-V as of the current 8.x and 9.x releases, which is exactly why this manual export-and-convert route exists.

Conclusion

None of this is difficult once you've seen it laid out — it's just unfamiliar the first time, and Microsoft and Proxmox obviously don't document each other's migration paths. The two things that actually trip people up are the Generation 1/2 BIOS mismatch and jumping straight to VirtIO SCSI before Windows has the driver for it. Get those two right and the rest is just waiting on file copies. Once the VM is up, activated, and running the full VirtIO driver set, it'll perform better than it did under Hyper-V in most cases — paravirtualized disk I/O tends to beat Hyper-V's synthetic drivers on the same hardware.