Introduction

Say you've been running Hyper-V on a Windows Server box for a few years. It works, mostly. But Windows Server 2025 dropped the free Hyper-V Server edition entirely, so now every host needs a paid Windows Server license just to run VMs. That's the moment a lot of small business owners and homelab users start typing "proxmox vs hyper-v" into Google at 11pm.

This guide walks through the real differences between the two platforms, then shows you exactly how to pull a VM off Hyper-V and get it running on Proxmox VE 9.2. No fluff, no "it depends" hand-waving — just what changes, what breaks, and how to fix it when it does.

What You Will Learn

  • The practical differences between Proxmox VE and Hyper-V — licensing, architecture, and day-to-day management
  • Why Proxmox handles containers differently, and why that matters for resource use
  • How to export a VHDX disk from Hyper-V and import it into Proxmox VE with qm disk import
  • The classic "INACCESSIBLE_BOOT_DEVICE" error Windows guests throw after migration, and how to avoid it
  • A short decision framework for which platform actually fits your situation

What Is This Feature?

Proxmox VE is a free, open-source virtualization platform built on Debian Linux. Under the hood it uses KVM for full virtual machines and LXC for lightweight Linux containers, with a web interface on top for managing everything — VMs, storage, networking, backups, users. You install it directly on bare metal, the same way you'd install Windows Server.

Hyper-V is Microsoft's hypervisor, built into Windows Server (and, in a limited form, into Windows 10/11 Pro). It uses its own VHD/VHDX disk format and its own management tools — either Hyper-V Manager for a single host, or Windows Admin Center / SCVMM if you're managing a cluster.

Both are "type 1" hypervisors in the sense that they run close to the hardware rather than on top of a general-purpose OS. The real differences show up in licensing, in how containers work, and in what storage options you get.

Why Would You Use It?

The honest answer for most homelab users and small businesses: cost. Proxmox VE is free with every feature turned on by default — clustering, live migration, backups, the works. The optional support subscription is for businesses that want a support contract and access to the Enterprise repository; it's not a license fee, and nothing stops functioning if you don't buy it.

Hyper-V, on the other hand, is tied to Windows Server licensing. Since the free Hyper-V Server edition was retired, every host running Hyper-V needs a Standard or Datacenter license, and Datacenter (which you'll want if you're running more than a couple of Windows guest VMs, since it includes unlimited Windows VM licensing on that host) runs into the thousands per host.

There's also LXC. If you're mostly hosting Linux services — a Pi-hole instance, a Plex server, a handful of web apps — an LXC container uses a fraction of the RAM and disk of a full VM because it shares the host's kernel instead of booting its own. Hyper-V has nothing directly equivalent; Windows Containers exist but they're a different beast entirely and mostly used for application containers, not general-purpose lightweight VMs.

None of this means Hyper-V is a bad product. If your shop is already deep in the Microsoft ecosystem — Active Directory, System Center, Azure Arc — the integration story is real, and retraining staff has a cost too. This isn't a "Proxmox is always better" argument. It's a "here's what you're actually trading off" argument.

FactorProxmox VEHyper-V
Base costFree, open sourceRequires a Windows Server license
Lightweight containersLXC, built inNot really — Windows Containers are application-level
ManagementWeb UI, works from any browserHyper-V Manager, Windows Admin Center, or SCVMM
Clustering / HAIncluded, no extra licenseRequires Datacenter edition and Failover Clustering
Storage optionsZFS, Ceph, LVM-thin, NFS, iSCSI, directoryNTFS/ReFS, Storage Spaces, SMB3 shares
Best fitHomelabs, mixed Linux/Windows shops, cost-sensitive teamsShops already standardized on Microsoft tooling

Prerequisites

Before you start moving a VM over, make sure you've got:

  • A working Proxmox VE 9.x install, with at least as much free storage as the VHDX file you're importing
  • Root or SSH access to the Proxmox host's shell (the GUI's Import Wizard doesn't cover Hyper-V sources, so this part is command-line only)
  • The VM shut down cleanly on the Hyper-V side — not saved-state, actually shut down
  • Any Hyper-V checkpoints (Microsoft's term for snapshots) merged or deleted first. A VHDX that's still part of a checkpoint chain is a differencing disk, and Proxmox can't make sense of that chain on its own
  • A way to copy the VHDX file to the Proxmox host — SCP, an SMB share, or a USB drive all work
  • For Windows guests, the VirtIO driver ISO downloaded ahead of time from the Proxmox website, because you'll need it during first boot

Fifteen minutes of prep here saves you an hour of troubleshooting later. Skipping the checkpoint merge step is the single most common reason these migrations go sideways.

Step-by-Step Tutorial

This walkthrough assumes a Windows guest with one VHDX disk, migrating from a Hyper-V host to a Proxmox VE 9.2 node called pve1, importing into local ZFS storage.

Step 1: Shut down and export the VM

In Hyper-V Manager, right-click the VM and choose Turn Off (not just Shut Down inside the guest — make sure Hyper-V shows the VM as Off). If there are checkpoints listed under the VM, delete them and let Hyper-V finish merging the disk chain before moving on. This can take a few minutes for large disks.

Locate the VHDX file — by default it's under C:\ProgramData\Microsoft\Windows\Virtual Hard Disks\ unless you configured a custom path when you created the VM.

Step 2: Copy the VHDX to the Proxmox host

From the Proxmox host's shell, pull the file over with SCP (or push it from the Windows side using something like WinSCP):

scp administrator@hyperv-host:"C:\ProgramData\Microsoft\Windows\Virtual Hard Disks\myserver.vhdx" /var/lib/vz/template/import/

A 60 GB disk takes a while over a 1 Gbps link — budget roughly 10-15 minutes per 100 GB, longer if the disk is thin and mostly empty, since Windows still writes it as one large file by default.

Step 3: Create an empty VM shell in Proxmox

In the Proxmox web UI, click Create VM. Fill in the general details, set the OS type to Windows, but on the Disks tab, delete the default disk that gets created — you don't need it, since you're importing one. Finish the wizard so you end up with a VM that has a VMID (say, 130) but no disk attached yet.

Step 4: Import the VHDX

Back in the shell, run:

qm disk import 130 /var/lib/vz/template/import/myserver.vhdx local-zfs --format qcow2

This reads the VHDX and converts it into a new disk image on the local-zfs storage, attached to VM 130 as an unused disk. QEMU handles the VHDX format natively, so there's no separate conversion tool to install.

Step 5: Attach the disk and set the boot order

Open the VM's Hardware tab in the GUI. You'll see the imported disk listed as Unused Disk 0. Double-click it, and for a Windows guest, attach it as SATA0 for now rather than SCSI or VirtIO — Windows doesn't ship with VirtIO drivers out of the box, and a Windows install that boots straight to a VirtIO controller it doesn't recognize will blue-screen. Then go to Options → Boot Order and make sure that disk is first.

Step 6: Attach the VirtIO driver ISO and boot

Add a second CD/DVD drive to the VM and mount the VirtIO driver ISO you downloaded earlier. Start the VM. Windows should boot normally off the SATA disk. Once you're logged in, open Device Manager, and install the VirtIO drivers from the mounted ISO for any devices showing as unrecognized (network adapter, balloon driver, and so on).

Step 7: Switch to VirtIO for better performance (optional but recommended)

Once the VirtIO storage driver is installed inside Windows, shut the VM down, change the disk's bus in the Hardware tab from SATA to VirtIO SCSI, and boot again. This gets you noticeably better disk throughput than emulated SATA, which matters if this is a database or file server.

Commands Explained

qm disk import <vmid> <path> <storage> --format qcow2 — imports an external disk image (VHDX, VHD, VMDK, or raw) into Proxmox storage and attaches it to the given VM as an unused disk. The --format flag sets the resulting image format; leave it off and Proxmox uses the target storage's default.

qm importdisk is the older name for the same command — both work identically on current Proxmox VE releases, so you'll see either in forum posts and older guides.

qm set 130 --scsi0 local-zfs:vm-130-disk-1 — an alternative to the GUI step, this attaches an already-imported disk to a VM via a specific bus and slot from the command line.

qm start 130 — boots the VM. Useful for scripting a migration instead of clicking through the GUI each time.

Common Errors

The error you'll hit most often is a Windows blue screen reading INACCESSIBLE_BOOT_DEVICE (0x0000007B) right after first boot. This happens when the disk is attached as VirtIO or SCSI before Windows has the driver for that controller loaded — Windows can't find its own boot disk and panics. The fix is exactly what Step 5 above covers: boot on SATA first, install VirtIO drivers, then switch the bus.

Another common one: qm disk import fails with something like unable to open file - No such file or directory. Nine times out of ten this is a typo in the path, or forgetting that Windows paths use backslashes that need quoting when you're copying the file with SCP from a Linux shell.

If the import command instead complains about the VHDX being a differencing disk or referencing a parent file that doesn't exist, that means the checkpoint merge from Step 1 didn't actually finish. Go back to Hyper-V Manager, confirm there are zero checkpoints left on the VM, and re-export.

Troubleshooting

VM boots but has no network? That's almost always the VirtIO network driver not being installed yet. Check Device Manager for an "Ethernet Controller" with a yellow warning icon and point it at the VirtIO ISO.

Disk import finishes but is much smaller or larger than you expected? Check the --format you used. A VHDX that's dynamically expanding (thin-provisioned on the Hyper-V side) will convert into a full-size raw image unless you're importing to a storage type that supports thin provisioning, like ZFS or LVM-thin with the right flags.

VM feels sluggish after migration compared to how it ran on Hyper-V? Confirm you actually switched the disk bus to VirtIO SCSI in Step 7 — a lot of people import the disk, get it booting, and forget to come back and do that step, so they're stuck on emulated SATA speeds indefinitely.

Guest shows the wrong time after migration? Windows VMs sometimes get confused about hardware clock source after a hypervisor change. Installing the QEMU Guest Agent (a small service that lets Proxmox and the guest OS talk to each other for things like clean shutdowns and accurate resource reporting) usually resolves this, along with a manual time resync from Windows settings.

Best Practices

  • Keep the original Hyper-V VM powered off, not deleted, until you've confirmed the migrated VM boots, has network, and passes whatever smoke test matters for that workload. Don't decommission the source until you're actually sure.
  • Migrate during a maintenance window. There's no live migration path between Hyper-V and Proxmox — this is an offline, downtime-required move, not a hot migration.
  • Test the boot process on a copy first if the VM is business-critical. Import the VHDX to a throwaway VMID, verify it boots clean, then repeat the process for real (or just keep that test VM as the real one).
  • Install the QEMU Guest Agent inside the guest once it's stable on Proxmox. It's a small download but it makes backups cleaner and shutdown/restart from the Proxmox GUI actually graceful instead of a hard power-off.
  • If you're migrating more than a handful of VMs, script the copy and import steps rather than doing it by hand each time — it's the same five commands repeated, and typos in VMIDs are an easy way to overwrite the wrong disk.

Frequently Asked Questions

Does Proxmox have a built-in Hyper-V import wizard, like it does for VMware?

No. The GUI Import Wizard covers VMware ESXi (since PVE 8.2) and OVA/OVF files (since PVE 8.3). Hyper-V isn't a supported source there, so the qm disk import shell command is the official path.

Is Proxmox VE really free for production use?

Yes. Every feature — clustering, HA, live migration, ZFS, backups — is available without a subscription. The paid subscription buys you access to the more conservative Enterprise repository and a support contract, not extra functionality.

Can I still run Windows Server as a guest on Proxmox?

Yes, but you still need a valid Windows Server license for that guest — moving the hypervisor doesn't change Microsoft's licensing requirements for the guest OS itself.

What happens to my Hyper-V checkpoints during migration?

They don't carry over. You need to merge or delete them before exporting the VHDX, and you'll start fresh with Proxmox's own snapshot system afterward.

Do I have to convert VHDX to a different format manually?

qm disk import reads VHDX directly and writes it out as whatever target format you specify — there's no separate conversion tool needed.

Conclusion

If cost and openness matter more to you than staying inside the Microsoft ecosystem, Proxmox is a genuinely solid landing spot for VMs coming off Hyper-V — and the migration itself, while manual, isn't hard once you know the INACCESSIBLE_BOOT_DEVICE trick. Budget a maintenance window, keep the source VM around until you've verified the new one, and you can move a typical Windows VM over in well under an hour once you've done it once or twice.