quemu windows guest boots into bluescreen after kernel update to 4.12.14-lp150.12.25-default

After updating to kernel 4.12.14-lp150.12.25-default my qemu Windows 7 guest boots into a bluescreen.

When I boot my Leap 15.0 installation with the old kernel (Version 4.12.14-lp150.12.22-default) the win 7 guest boots without problems. I have also a Win XP guest which freezes while booting with the new kernel and works fine with old one.

That’s my qemu command line:
qemu-system-i386 -vga std -monitor stdio -rtc base=localtime -m 2G -enable-kvm -soundhw hda -usb -device usb-ehci,id=ehci -net nic,macaddr=52:54:12:34:56:00,model=virtio -net user,smb=/home/hriesenb/vshared/windows -device virtio-balloon -drive file=Win7Prof32Bit_C.cow,index=0,media=disk,if=virtio -drive file=/vdata/data/WinData_D.cow,index=1,media=disk,if=virtio

Removing the -enable-kvm option lets the windows guests boot without failure with new kernel, but they are very slow as expected.

Has anyone and idea?

Best regards
Hartmut

Hi,

No idea but same problem here with Leap 15.0 and the new kernel. I have two guests (Centos 7 and Windows Server 2016) and both fail to start after reboot with the new kernel The Centos guest shows the boot screen but hangs after this - didn’t try seeing what happens with the windows guest.

Booted with the old kernel 4.12.14-lp150.12.22-default and the two VMs also start OK here.

Didn’t try the combination new kernel and removing the “-enable-kvm” switch.

Also waiting for an idea,

Carlos

No certain idea about your current problem, but some suggestions…

I’ve found the SUSE 11 SP4 documentation a good reference, you might skim the QEMU sections to see if there’s anything in there you might find helpful…

https://www.suse.com/documentation/sles11/singlehtml/book_kvm/book_kvm.html

You can also skim the current SUSE 12 SP3 documentation, there may still be terminology and concept issues I’ve criticized, but if you consider yourself well-grounded in your understanding of virtualization, those should not be an issue for you

https://www.suse.com/documentation/sles-12/singlehtml/book_virt/book_virt.html

I’d also ask if there is a reason why you’re running qemu-kvm instead of kvm proper.
AFAIK if you don’t have a particular reason to be running qemu-kvm, kvm proper should perform better… but who knows, perhaps technology progressed far enough there shouldn’t be much of a difference anymore.

IMO you should also inspect your bootlogs to determine at what point you boot into the bluescreen, the usual command to extract the previous (or any other) bootlog

journalctl -b -1

TSU

Thanks for reply TSU!

There is nothing strange in the bootlog nor in the systemlog while booting the windows guest.

I will take a look into the the documentation you provided. May kvm will do a better job for me.

Cheers
Hartmut

Same here after the kernel update on LEAP 15. I have one VM with Windows 2012R2 running, KVM drivers v0.1.160 are installed into the client (video “Red Hat QXL”, hard drive “Red Hat VirtIO SCSI Disk Device”, network “Red Hat VirtIO Ethernet Adapter”, storage “Red Hat VirtIO SCSI controller”, system devices “VirtIO Balloon Driver, VirtIO Serial driver”, service “QEMU Guest Agent” running) from “latest virtio-win iso” from here:

https://docs.fedoraproject.org/en-US/quick-docs/creating-windows-virtual-machines-using-virtio-drivers/index.html

Windows client is booting into blue screen with new kernel (“boot drive/partition unavailable” or something similar). Returning to previous kernel all is fine. I could post the XML dump of the VM but I don’t see how to append files (below it says “you may not post attachments”), or should I include the full text (140 lines) in a post?

Harald

If you want to post something extremely large or not supported by these forums, post to a pastebin and then include a link to your pastebin post in your Forum post…

A couple of pastebins…
https://paste.opensuse.org/

Since you are the second person to post about a similar and possibly same issue,
I’d also recommend you submit a bug to https://bugzilla.opensuse.org and include a link to this Forum thread.

Be detailed.
You should include your method of managing your vms (eg command as the @OP posted or if you’re using libvirt) and whether you’re running KVM or QEMU-KVM.

TSU

Ok, thank you for the reply. I posted my VM XML here: https://paste.opensuse.org/54946116

I did not create/start my VM by a command line. I just enabled KVM in yast and created the VM with the graphical tool included in openSUSE and set it to autostart.

The settings from the command line like MAC address are in my case in the XML I posted. I assume this uses libvirt but am not sure to be honest. So the VM starts whenever I boot my openSUSE server machine. And I can start/stop the VM manually by “virsh start win2k12r2” and “virsh shutdown win2k12r2”.

Although the machine configuration (XML) file is useful,
I’m pretty sure some info from the Windows bootlog would be important to understanding what might be necessary to fix the problem.
In Windows, this information can be found in the Event Viewer.

TSU

Ok, but I have to re-create this when I have spare time. Because when the issue happened I not only reverted the openSUSE machine to the previous kernel but also the VM virtual HDD to a backup of the day before. As I didn’t know at first what was the cause for the blue screen I tried to avoid running a probably damaged windows image. So the event logs from the crash are not in the currently running image (if there were entries at all, as the blue screen told about missing/inaccessible partition or drive, so perhaps windows couldn’t write event log entries of the problem to the “missing drive” at all).

When I find time to force the crash again I look for event log and post it here. As the VM is 24/7 a windows software update server (WSUS) for >50 clients I have to try on a weekend or holiday.

Today I did the test. As there was a new kernel 4.12.14-lp150.12.28-default (beside other updates, one for qemu) after a backup I tried with the new kernel. Same issue like with .12.25, the VM didn’t boot. After changing grub config back to boot older kernel 12.22 the VM came up again. All other packages remained updated to the latest version. In Windows event viewer (eventvwr.msc) of the vm guest there were no entries for the failed boot. Obviously because the virtual disk couldn’t be accessed on boot there also error events could not be saved to the inaccessible drive.

https://i.paste.pics/8d6c6297b667813105e17615954b5288.png

If you inspect your Windows system logs using the Event Viewer, you should find all the events related to your failed boot.

TSU

Sorry, unfortunately not. All event logs (system, application, …) end with the successful shutdown before kernel upgrade, show nothing of the failed boot with new kernel and continue with the successful boot after returning to the old kernel.

In failure state the guest does not find the system drive at all, so is unable to boot or write events to the log on the missing system drive :frowning:

You should look for the entries that relate only to your failed boot.
They’re there, and you’ll find entries that likely relate to your blue screen.
BTW -
Usually the Windows Blue Screen for Win8 and later also contain an error at the bottom… It may be helpful but I’ve found may not be enough to get the whole picture… You’ll more likely need the full error plus what leads up to that error.

TSU

Just for the records: 2018 when the problem occurred I decided to stay with kernel 4.12.14-lp150.12.22-default. The next 5-6(?) kernel updates I tried always resulted in a guest blue screen so I rolled back to lp150.12.22 after each try. And there was no useful info on the bluescreen itself nor any log entry on the virtual disk (I’m a software engineer, familiar with windows and know where I would have to look).

But after some time (sorry, don’t remember the exact kernel number) the issue was obviously resolved and after a kernel update the vm guest booted ok. From then I applied every kernel update, upgraded the installation from LEAP 15.0 to LEAP 15.1 and everything is still fine. The guest vm is still booting and working normally without having to change anything in the virtualization or guest settings. So it was an intermediate problem of some kernel versions, fortunately resolved.