Fix Windows INACCESSIBLE_BOOT_DEVICE after a VMware to Proxmox migration
A Windows VM that ran fine on VMware stops with the blue screen INACCESSIBLE_BOOT_DEVICE (stop code 0x0000007B) on its first boot on Proxmox VE, oVirt / OLVM or any KVM hypervisor when its system disk hangs off a VirtIO controller and Windows has no VirtIO storage driver set to load at boot. The data is intact. The fix is to boot once from a controller Windows already knows, install the driver and switch back, or to inject the driver offline.
Why it happens
On VMware the system disk hangs off an LSI Logic SAS or a VMware Paravirtual (PVSCSI) controller, and Windows only starts at boot the storage drivers it needed the last time it ran. On KVM the fast controllers are VirtIO SCSI, driven by vioscsi, and VirtIO Block, driven by viostor. Neither ships with Windows. The kernel loads, looks for the boot volume through a controller it has no driver for, and stops with 0x7B.
Installing the VirtIO drivers while the VM is still on VMware is often not enough. The installer stages them in the driver store, but with no VirtIO device present Windows does not mark the storage driver as boot-start, so the first boot on a VirtIO controller can fail in exactly the same way.
A second, unrelated cause leads to a similar dead end: firmware. A VM that booted with UEFI on VMware has to be created with OVMF and an EFI disk on the target, and a BIOS VM with SeaBIOS. The UEFI boot entries live in the NVRAM file VMware keeps next to the VM, which does not travel with the disk.
Fix it by hand
These steps are written for Proxmox VE, where the problem is reported most often, and apply the same way to any KVM hypervisor. The first five are the usual path. The last one is for a Windows that will not boot from any controller.
- 01Match the firmware
Check whether the VM used BIOS or EFI on VMware and set the same on the target: OVMF plus an EFI disk for UEFI, SeaBIOS for BIOS. On Proxmox it is the BIOS field under Hardware.
- 02Boot once from SATA
Detach the system disk and attach it again as SATA. Windows carries an inbox AHCI driver, so it boots. Put that disk first in the boot order.
- 03Add a temporary VirtIO disk
With the VM off, set the SCSI controller to VirtIO SCSI, add a 1 GB disk on it and mount the virtio-win ISO as a CD-ROM. The small disk gives Windows a real VirtIO device to bind the driver to.
- 04Install the VirtIO storage driver
Start Windows and run virtio-win-gt-x64.msi from the ISO, or install only the storage drivers from an elevated prompt. Replace 2k22 with the folder for your version: 2k16, 2k19, 2k22 or 2k25. When the 1 GB disk shows up in Disk Management, the driver is bound.
pnputil /add-driver E:\vioscsi\2k22\amd64\vioscsi.inf /install pnputil /add-driver E:\viostor\2k22\amd64\viostor.inf /install - 05Move the system disk to VirtIO SCSI
Shut down, detach the system disk again and attach it as SCSI. Fix the boot order and start the VM. Once it boots, remove the temporary disk.
- 06If Windows does not boot from any controller, inject the driver offline
Boot the Windows installation ISO, choose Repair your computer and open the Command Prompt. drvload makes the disk visible to the recovery environment and dism adds the driver to the installed Windows. Drive letters change in recovery: check them with diskpart and list volume before running the commands.
drvload E:\vioscsi\2k22\amd64\vioscsi.inf dism /image:C:\ /add-driver /driver:E:\vioscsi\2k22\amd64\vioscsi.inf
How Moov avoids it
Moov prepares the guest before its first boot on the target. The customize stage runs offline against the mounted disk, so there is no first boot from SATA, no temporary disk and no second shutdown.
Download the appliance
- The VirtIO storage drivers, vioscsi and viostor, are injected into Windows with the VM powered off, as files and in the registry, which is what lets the disk sit on virtio-scsi from the first start.
- The network, balloon and serial drivers and the QEMU guest agent are installed by Windows on that first boot, with nothing to do by hand.
- The BCD fixup runs on Windows, and on guests that boot via UEFI the ESP partition is seeded or repaired.
- BIOS guests on MBR disks boot even when Windows does not live on disk 0.
- Windows Server 2016 gets its own VirtIO drivers, and you choose the virtio-win version per target connection or per VM.
- After the migration Moov powers the VM on and waits for the QEMU guest agent. The wave reports verified, inconclusive or failed instead of turning green just because the disks copied.
Frequently asked questions
- What does INACCESSIBLE_BOOT_DEVICE mean?
- It is the Windows stop code 0x0000007B: the kernel started but could not reach the volume it boots from. After a change of hypervisor the cause is almost always a missing storage controller driver, not a damaged disk.
- Did I lose my data?
- No. The disk is intact and Windows simply cannot see it through the new controller. Attach it as SATA and it boots.
- Can I just leave the disk on SATA?
- It works, but SATA is an emulated controller and is slower under load. VirtIO SCSI is the bus Proxmox recommends for Windows guests.
- Does it happen on Windows Server 2016, 2019, 2022 and 2025?
- Yes, and on Windows 10 and 11 as well: none of them ships the VirtIO storage drivers. Only the folder you take the driver from changes: 2k16, 2k19, 2k22, 2k25, w10 or w11.
- Does it also happen with other migration methods?
- It can happen with any method that copies the disk without preparing the guest: a direct import from the source hypervisor, a manual disk conversion or a plain disk restore. The fix is the same in all of them.