Migrating virtual servers between hypervisors can look like a disk operation.
Export the VM.
Move the disk.
Attach it to the new hypervisor.
Start the server.
With Linux, the first visible issue is often a changed network adapter name or a boot configuration detail. With Windows servers, the problem may be different: which storage controller Windows expects during boot, and which controller the new hypervisor presents after the migration.
During a migration from Microsoft Hyper-V to Proxmox VE, we wanted a method that was simple, controlled, and still allowed us to return to the original VM if needed.
In the end, we used the free Veeam Backup & Replication Community Edition.
The backup and restore itself worked well. The problem appeared only during the first boot of the restored Windows VM on Proxmox.
Windows ended in a blue screen and then repeatedly started:
Preparing Automatic Repair
Automatic RepairWhy we used Veeam
There are several ways to migrate a VM from Hyper-V to Proxmox.
You can work directly with the disks, convert VHDX files, manually move them to Proxmox storage, attach them to a new VM and then fix the hardware configuration.
For this migration, we wanted a process that was:
- simple,
- controlled,
- safe from a rollback perspective,
- usable without manually converting disks,
- appropriate for a real Windows server.
That is why we chose Veeam Backup & Replication Community Edition.
The advantage of this approach is that the original Hyper-V VM remains preserved. The migration is done through backup and restore, not through a destructive move of the original virtual disk.
If something goes wrong, the original VM and the backup still exist.
Backup and restore through Veeam
The basic process was straightforward.
First, we added the Hyper-V virtual server to Veeam.
Then we created a full backup of the VM.
After that, we added Proxmox VE as the target virtualization platform and restored the whole VM from the backup directly to Proxmox.
In simplified form:
Hyper-V VM
↓
Veeam Backup
↓
Restore to Proxmox VE
↓
New VM on ProxmoxThis part completed without major problems.
Veeam created the backup.
The restore to Proxmox completed.
The VM was created on Proxmox.
The virtual disk was restored.
At first glance, everything looked fine.
The problem started when Windows tried to boot.
The problem: BSOD and Automatic Repair
Before the migration, while the VM was still running on Hyper-V, we installed the VirtIO drivers inside Windows.
That is a common preparation step for Windows VMs that will run on Proxmox, because Proxmox uses VirtIO drivers for more efficient communication with virtual disks, network adapters and other virtual devices.
The assumption was simple:
If VirtIO drivers are installed in Windows before the migration, Windows should boot normally after it is restored on Proxmox.
But it did not.
After starting the VM on Proxmox, Windows blue-screened and then repeatedly entered Automatic Repair:
Preparing Automatic Repair
Automatic RepairAt first, this can look like a corrupted restore, a damaged disk, a bootloader issue or a failed migration.
In this case, the Veeam restore itself was not the real problem.
The issue was the storage driver used during boot.
The real cause: the VirtIO driver was installed, but not used for the boot disk
The system disk was attached on Proxmox through VirtIO SCSI.
Windows had VirtIO drivers installed, but while it was still on Hyper-V, it had never actually used VirtIO SCSI for the boot disk.
That difference matters.
A driver can be present in the operating system, but Windows may not have it ready as a boot-critical driver for a specific storage controller if that controller was never actually detected during normal system operation.
On Hyper-V, Windows booted through a Hyper-V storage controller. After the restore on Proxmox, it was suddenly expected to boot from a system disk attached through VirtIO SCSI.
The result looked like this:
Windows has VirtIO drivers installed
Windows has never used VirtIO SCSI as a disk controller
After migration, the system disk is attached through VirtIO SCSI
During boot, Windows cannot access the system disk correctly
Boot ends in BSOD / Automatic RepairThis was the main diagnostic lesson:
Installing VirtIO drivers on Hyper-V may not be enough. Windows needs to actually see the VirtIO SCSI controller and activate the driver before it is expected to boot from it.
The fix: SATA first, then VirtIO SCSI
The working solution was surprisingly simple.
Instead of immediately repairing the Windows bootloader or repeating the restore, we changed how the system disk was attached.
The goal was to let Windows boot first through a more compatible controller and then teach it to use VirtIO SCSI.
The process was:
Attach the system disk temporarily as SATA
Let Windows boot successfully
Add a small helper VirtIO SCSI disk
Let Windows detect the VirtIO SCSI controller
Install or activate the correct driver
Shut down the VM
Move the system disk back to VirtIO SCSI1. Detach the system disk
With the VM powered off, we opened the Proxmox hardware view:
VM → HardwareThe system disk was detached from the VM using:
DetachThe important word is Detach.
Do not delete the disk.
Do not remove it from storage.
Do not perform any destructive operation.
After detaching it, the disk appeared in Proxmox as:
Unused DiskThat means the disk still exists, but it is not currently attached to the VM as an active boot device.
2. Attach the system disk temporarily through SATA
We then attached the same disk again as:
SATA0and set it as the boot disk.
After this change, Windows booted normally.
That was an important confirmation.
It meant that:
- the Veeam restore was valid,
- the Windows installation was not corrupted,
- the system disk was readable,
- the issue was not primarily the bootloader,
- the issue was the storage controller used during boot.
In other words: Windows could boot from the same disk, just not through VirtIO SCSI in its original restored state.
3. Add a small VirtIO SCSI helper disk
Once Windows was running through SATA, we added a new helper disk to the VM.
A small disk was enough, for example:
1 GBThis disk was attached through:
SCSI / VirtIO SCSIIts purpose was not to store data.
Its only purpose was to make Windows see a real VirtIO SCSI controller while the system was running normally.
This was the decisive step.
Windows was no longer in the boot phase. It had access to the system disk through SATA, and it also received a new VirtIO SCSI device that it could detect, bind to the correct driver and store as a usable storage driver.
4. Install or activate the VirtIO SCSI driver
We attached the VirtIO driver ISO to the VM:
virtio-win.isoThen, inside Windows, we checked Device Manager.
After adding the SCSI disk, Windows detected the new storage controller. It was then possible to install or activate:
Red Hat VirtIO SCSIThis explains why installing the VirtIO package earlier on Hyper-V was not enough.
Windows may have had the driver files available, but if it had never seen the corresponding VirtIO SCSI device, the driver was not necessarily ready to be used during boot from the system disk.
Practically speaking:
driver installedis not always the same as:
driver active and ready for boot5. Move the system disk back to SCSI
After the VirtIO SCSI driver was successfully installed or activated, we shut Windows down properly.
Then we made the final Proxmox hardware change:
- detached the system disk from
SATA0, - attached it again as
SCSI0, - used the VirtIO SCSI controller,
- set
SCSI0as the boot disk.
After powering on the VM, Windows booted successfully from the system disk attached through VirtIO SCSI.
The temporary 1 GB helper disk was no longer needed and could be removed.
The whole process in short
The working migration path looked like this:
Hyper-V VM
↓
Veeam Backup
↓
Restore to Proxmox VE
↓
Windows BSOD / Automatic Repair
↓
Detach the system disk
↓
Attach the system disk as SATA0
↓
Windows boots successfully
↓
Add a 1 GB VirtIO SCSI disk
↓
Install / activate the VirtIO SCSI driver
↓
Shut down the VM
↓
System disk SATA0 → SCSI0
↓
Successful boot through VirtIO SCSIWhat to check before the migration
Before migrating a Windows VM from Hyper-V to Proxmox, it is worth checking:
- that a current and verifiable backup exists,
- that the original Hyper-V VM remains available for rollback,
- that the Veeam restore path is known,
- that
virtio-win.isois ready, - that VirtIO drivers are available inside Windows,
- which storage controller will be used after restore,
- whether the VM uses BIOS or UEFI boot,
- whether the VM generation and boot mode are configured correctly,
- what the first-boot plan on Proxmox will be.
Especially with a production Windows server, a successful restore should not be confused with a successful boot.
What to check after restoring to Proxmox
After restoring the VM to Proxmox, verify the layers step by step:
VM hardware configuration
boot order
disk controller
Windows boot
Device Manager
VirtIO SCSI driver
network adapter
Windows event logs
application services
backup state after migrationIf Windows enters Automatic Repair, it does not automatically mean that the restore failed.
First, check whether Windows can boot from the same disk through another controller, such as SATA.
If it can, the problem is very likely the storage driver, not the data on the disk.
The main lesson
The most important finding was that installing VirtIO drivers before the migration may not be enough.
Windows can have the driver stored in the system, but if it never saw the corresponding VirtIO SCSI controller while running on Hyper-V, it may not be ready to use that driver during boot.
The practical trick was simple:
If a migrated Windows VM does not boot through VirtIO SCSI after restore on Proxmox, attach the system disk temporarily through SATA, add a small helper VirtIO SCSI disk, let Windows load the correct VirtIO driver, and only then move the system disk back to SCSI.
This resolved the BSOD and Automatic Repair loop without manually converting VHDX disks or repeating the whole migration.
Conclusion
The migration of a Windows virtual server from Hyper-V to Proxmox VE using Veeam Backup & Replication Community Edition succeeded without manual disk conversion.
Veeam acted as a safe migration layer: first a backup of the Hyper-V VM, then a restore to Proxmox.
But the restore itself does not remove the difference between the storage controller Windows used on Hyper-V and the storage controller it must use on Proxmox.
That is why, for Windows VMs, it is important to think not only about the disk as a file, but also about the driver Windows needs during boot.
In this case, the successful path was:
Restore through Veeam
Temporary boot through SATA
Activate VirtIO SCSI with a helper disk
Final boot through VirtIO SCSIAnd the core lesson is:
{"research-hyper-v":{"title":"Hyper-V","summary":"Technical profile of Microsoft Hyper-V as a Windows virtualization technology and migration source platform, with focus on guest hardware assumptions, backups, drivers, restore planning and operational risk.","url":"/research/hyper-v/","links":[{"title":"Hyper-V virtualization in Windows Server and Windows","type":"official-documentation","url":"https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/hyper-v-technology-overview"},{"title":"Install Hyper-V in Windows and Windows Server","type":"official-documentation","url":"https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/install-the-hyper-v-role-on-windows-server"},{"title":"Plan for Hyper-V on Windows Server","type":"official-documentation","url":"https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-hyper-v-on-windows-server"},{"title":"Hyper-V PowerShell module","type":"official-documentation","url":"https://learn.microsoft.com/en-us/powershell/module/hyper-v/"},{"title":"Migrating a Windows VM from Hyper-V to Proxmox with Veeam Community Edition","type":"my-blog","url":"/blog/migrating-windows-vm-from-hyper-v-to-proxmox-with-veeam-community-edition/"}]},"research-proxmox-ve":{"title":"Proxmox VE","summary":"Technical profile of Proxmox VE as an open-source virtualization platform for KVM virtual machines and containers, with focus on migration, storage, networking, backup, restore and operational risk.","url":"/research/proxmox-ve/","links":[{"title":"Proxmox VE official overview","type":"official-website","url":"https://www.proxmox.com/en/proxmox-virtual-environment/overview"},{"title":"Proxmox VE Documentation Index","type":"official-documentation","url":"https://pve.proxmox.com/pve-docs/"},{"title":"Proxmox VE Administration Guide","type":"official-documentation","url":"https://pve.proxmox.com/pve-docs/pve-admin-guide.html"},{"title":"Proxmox VE source repository - pve-manager","type":"source-code","url":"https://git.proxmox.com/?p=pve-manager.git"},{"title":"Migrating a Windows VM from Hyper-V to Proxmox with Veeam Community Edition","type":"my-blog","url":"/blog/migrating-windows-vm-from-hyper-v-to-proxmox-with-veeam-community-edition/"}]},"research-veeam-backup-replication":{"title":"Veeam Backup & Replication","summary":"Technical profile of Veeam Backup & Replication as a backup, restore and migration tool for virtualized workloads, with emphasis on restore verification, rollback and cross-platform recovery assumptions.","url":"/research/veeam-backup-replication/","links":[{"title":"Veeam Backup & Replication product page","type":"official-website","url":"https://www.veeam.com/products/veeam-data-platform/backup-recovery.html"},{"title":"About Veeam Backup & Replication","type":"official-documentation","url":"https://helpcenter.veeam.com/docs/vbr/userguide/overview.html"},{"title":"Veeam Community Edition","type":"official-website","url":"https://www.veeam.com/products/free/backup-recovery.html"},{"title":"Veeam Help Center","type":"official-documentation","url":"https://helpcenter.veeam.com/"},{"title":"Migrating a Windows VM from Hyper-V to Proxmox with Veeam Community Edition","type":"my-blog","url":"/blog/migrating-windows-vm-from-hyper-v-to-proxmox-with-veeam-community-edition/"}]}}For a Windows VM migration, it is not enough that VirtIO drivers are “installed”. Windows must be ready to use them for the actual boot storage controller.