How to Migrate from Hyper-V to Proxmox VE: Complete Guide

Why Migrate from Hyper-V to Proxmox?

Organizations migrate from Hyper-V to Proxmox for various reasons: reducing Windows Server licensing costs, consolidating on a Linux-based stack, gaining access to features like ZFS and Ceph without additional licensing, or simply preferring an open-source platform. Whatever the motivation, the migration process is straightforward once you understand the disk conversion and driver requirements.

Understanding the Disk Format Difference

Hyper-V uses two virtual disk formats: VHD (legacy, limited to 2 TB) and VHDX (current, supports up to 64 TB). Proxmox VE works with qcow2 and raw disk formats. The migration process centers around converting VHDX files to a format Proxmox can use.

Step 1: Prepare the Source VM

Before exporting, prepare the VM on the Hyper-V side:

• Remove Hyper-V Integration Services (for older Windows versions). Modern Windows versions include inbox integration components that do not interfere.
• Merge checkpoints: If the VM has checkpoints (snapshots), merge them into the base disk. Right-click the VM in Hyper-V Manager, select Delete checkpoint, and wait for the merge to complete.
• Note the configuration: Record CPU count, memory allocation, network adapters, and any special settings. Screenshot the VM settings for reference.
• Shut down the VM cleanly: Ensure a clean shutdown rather than saving state. Saved state files are not transferable.

Step 2: Locate and Copy the VHDX File

VHDX files are typically stored in C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Hard Disks\ or a custom path you configured. Copy the VHDX file to the Proxmox host:

# From a Linux workstation or the Proxmox host:
scp administrator@hyper-v-host:/C$/VMs/MyServer/MyServer.vhdx /tmp/imports/

# Or use SMB if the Hyper-V host has a file share:
smbclient //hyper-v-host/VMs -U administrator -c "get MyServer.vhdx /tmp/imports/MyServer.vhdx"

Step 3: Convert VHDX to Proxmox Format

On the Proxmox host, use qemu-img to convert the disk:

# Convert to qcow2 (best for directory-based storage):
qemu-img convert -f vhdx -O qcow2 /tmp/imports/MyServer.vhdx /tmp/imports/MyServer.qcow2

# Convert to raw (best for ZFS or LVM-thin storage):
qemu-img convert -f vhdx -O raw /tmp/imports/MyServer.vhdx /tmp/imports/MyServer.raw

# Check the conversion result:
qemu-img info /tmp/imports/MyServer.qcow2

For large disks, the conversion can take significant time. A 500 GB VHDX file might take 20-40 minutes depending on I/O speed. Add the -p flag to show progress:

qemu-img convert -p -f vhdx -O qcow2 /tmp/imports/MyServer.vhdx /tmp/imports/MyServer.qcow2

Step 4: Create and Configure the VM in Proxmox

Create a new VM in the Proxmox web UI or via command line, matching the source VM's configuration:

# Create the VM shell (no disk yet)
qm create 300 --name MyServer --memory 4096 --cores 4 --net0 virtio,bridge=vmbr0

# Import the converted disk
qm importdisk 300 /tmp/imports/MyServer.qcow2 local-lvm

# Attach the disk (verify disk name from importdisk output)
qm set 300 --scsi0 local-lvm:vm-300-disk-0 --scsihw virtio-scsi-single

# Set boot order
qm set 300 --boot order=scsi0

# Add a CD-ROM for VirtIO drivers (Windows VMs)
qm set 300 --ide2 local:iso/virtio-win.iso,media=cdrom

Step 5: Driver Replacement

Windows VMs

Windows VMs migrated from Hyper-V need VirtIO drivers for optimal performance:

1. On first boot, start the VM with the disk controller set to IDE or SCSI (not VirtIO) so Windows can boot with generic drivers.
2. Mount the VirtIO ISO inside the VM.
3. Install VirtIO storage drivers (vioscsi), network drivers (NetKVM), balloon driver (Balloon), and the QEMU guest agent from the ISO.
4. Shut down the VM, change the disk controller to VirtIO SCSI and the network adapter to VirtIO in Proxmox settings.
5. Boot and verify everything works correctly.

Linux VMs

Linux VMs generally boot without issues since the kernel includes VirtIO drivers. After first boot:

# Install QEMU guest agent
apt install qemu-guest-agent    # Debian/Ubuntu
dnf install qemu-guest-agent    # RHEL/Fedora

# Enable and start the agent
systemctl enable --now qemu-guest-agent

# Verify network interface names (they may change)
ip addr show

Step 6: Post-Migration Testing

Thoroughly test each migrated VM:

• Boot test: Verify the VM boots cleanly without errors.
• Network connectivity: Confirm IP addressing, DNS resolution, and connectivity to dependent services.
• Application testing: Start all services and verify they function correctly.
• Performance baseline: Compare disk I/O, network throughput, and CPU utilization against pre-migration baselines.
• Backup verification: Ensure the VM is included in your Proxmox Backup Server jobs and run a test backup.

Using ProxmoxR can simplify post-migration monitoring by giving you quick access to VM status, resource usage, and alerts from your phone — helpful when you are validating a batch of recently migrated systems and want to catch issues early.

Common Issues and Solutions