0

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: Guest OS BSOD screenshot.

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. Windows Error Recovery report

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

1 Answer 1

0

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.

4
  • There is no longer an IDE option available in virt-manager - only SATA, SCSI, USB and virtIO. So, I downloaded the Windows Guest virtio drivers ISO, mounted this and installed the drivers into the guest OS, created a small dummy drive (100MB .img fie) that uses virtio, appending the following to the qemu command: -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd -drive if=none,id=hd,file=vm/qemu/scsi_test.img,format=raw, and I now receive the same BSOD that I do when launching the same VM from virt-manager.
    – jimjamz
    Jan 8, 2023 at 14:11
  • I added the virtio device to the qemu command and launched the guest OS. This attempted to install the SCSI controller drivers, but obviously failed. I then downloaded and mounted the latest virtio driver ISO. The drivers installed successfully, and the guest OS starts as long as the virtio device is no longer called on the command line. If it is, I get the BSOD.
    – jimjamz
    Jan 8, 2023 at 14:17
  • So if I understand you correctly, with your OS virtual drive still on -hda, you also get a BSOD? In that case, I am out of ideas, sorry. Your best bet may be to start from scratch entirely.
    – Daniel B
    Jan 8, 2023 at 15:07
  • Yes, @Daniel B that's correct. The qemu command is the same as in the OP (still with -hda),but when I append -device virtio-scsi-pci,id=scsi once the virtio driver is installed within the guest, I get the BSOD. Before the driver was installed and appending -device virtio-scsi-pci,id=scsi, the guest VM would start successfully, but fail to install the SCSI controller because it could not recognise it.
    – jimjamz
    Jan 8, 2023 at 18:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .