Windows VM works from QEMU CLI but produces BSOD from virt-manager

Question

Overview

I have a Windows 7 virtual image that I can successfully spin up using the following qemu command in the terminal:

qemu-system-x86_64 -m 4096 -boot d -enable-kvm -smp 2 -net nic -net user -hda /home/jimjamz/vm/qemu/win7_enterprise.img

However, when I create a new VM in virt-manager by importing the existing disk image, I receive a BSOD immediately aftertrying to boot the guest OS:

Additional information

When importing the virtual disk image into virt-manager, I used the default configuration set by virt-manager. I did not make any changes.

I can boot into the Windows Error Recovery console within the guest OS, but it cannot find or resolve the issue.

dmesg -wH on the host reports nothing unusual:

[  +0.155447] audit: type=1400 audit(1669065509.580:83): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-9e0d5e45-b501-44d2-8aad-cf2120ef7065" pid=8911 comm="apparmor_parser"
[  +1.845672] virbr0: port 2(vnet0) entered learning state
[  +2.015921] virbr0: port 2(vnet0) entered forwarding state
[  +0.000001] virbr0: topology change detected, propagating

I then changed some of the VM hardware configuration in virt-manager, from dual to single core CPU, removed all non-priority emulated hardware devices (USB controllers, audio and ultimately the NIC and virtual network), but still I receive the BSOD.

I can see that every time I start the OS with virt-manager, it sets root:root permissions on the virtual image. If I change user and group permissions back to the local user (as it was when using only the qemu CLI), I can start the image from the QEMU CLI command as before, but not from virt-manager. I launched virt-manager as the root user, and attempted to start the VM, but I still receive the same BSOD, so I cannot conclude whether it is file permissions related.

Hypervisor details (from virt-manager):

• Hypervisor: KVM
• Arch: x86_64
• Emulator: /usr/bin/qemu-system-x86_64
• Chipset: Q35
• Firmware: BIOS
• Guest OS: Windows 7 Enterprise x64
• Host OS: Debian Buster variant
• QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u9)
• virt-manager 2.0.0

2024 UPDATE: I have been able to convert the VM image from PATA/IDE to virtual SCSI. This time, I used a different set of virtIO drivers to the ones used in my previous comment, instead using those from Red Hat.

My script to run qemu is as follows:

HDA_IMAGE=${HOME}/vm/qemu/win7_enterprise.img
CDROM_IMAGE=${HOME}/vm/virtio-win-0.1.173.iso

qemu-system-x86_64 \
-m 4096 \
-boot d \
-enable-kvm \
-smp 2 \
-net nic \
-net user \
-drive file=$CDROM_IMAGE,media=cdrom \
-device virtio-scsi-pci,id=scsi \
-device scsi-hd,drive=scsi-hd \
-drive if=none,id=scsi-hd,file=$HDA_IMAGE,format=qcow2 \
--display sdl

The VM successfully starts from the terminal qemu command. However, when I add that VM disk to a new VM in virt-manager, either with the SCSI or VirtIO bus types, the VM BSODs on startup in the same way it did before.

Answer 1

When you use -hda, QEMU creates a virtual IDE (PATA) controller and attaches a virtual IDE drive as the first device on the first channel. virt-manager probably uses virtual SCSI by default because it is more efficient/faster.

You can change the VM to have an IDE controller and attach the virtual hard drive there. It should then boot without issues.

If you want to switch, in addition to your hda virtual hard drive, add a small dummy drive using virtual SCSI. virtio SCSI ought to offer the best performance. After booting and installing all drivers, you can then switch the system drive to the virtual SCSI (or whatever) controller.

Windows is (in)famously incapable of booting of storage controllers that are not yet known and enabled. Back when AHCI (the SATA controller standard) was new, you had the same problems, especially with BIOS/UEFI setups where you can switch the SATA controller between IDE and AHCI or even RAID mode.