[Testing - Trixie] QEMU/KVM: Windows10 guest freezes after a few minutes

[hknox]

I updated the various qemu packages last weekend (2024.09.28). I have been running a Windows 10 guest quite successfully for several years but since the upgrade, Windows freezes after only a few minutes of use. It doesn't matter what I am doing: after a few minutes, the UI becomes totally unresponsive, clicking icons produces no response, I can't change windows or apps, and the cursor is a spinning wheel. I have waited as long as 10 minutes to see if anything comes back but there is nothing to do but close the instance by force. I don't know where to look for ideas: I can't find a log file for windows or qemu that gives any hints about what might be going on, and the Windows instance doesn't stay working long enough to look a the Windows Event manager. Can anyone suggest a way of debugging this? I tried upgrading the qemu to sid in the hope that something has been fixed since last weekend but that made no difference. I tried downgrading but couldn't manage the dependencies.

Thanks in advance for any help.
Hank Knox

[Aki]

Hello,

I'll be following the progress of your bug report:

• Debian Bug report logs - #1084199 qemu-sys: Windows 10 guest freezes after a few moments running under QEMU/KVM

[CwF]

In virt-managers viewer window, under details, there is a the performance view where you can see if the vm is alive. You could send keystrokes to the vm, like Ctrl-Alt-Delete, and check if the host can pause, resume, shutdown and generally communicate with the vm assuming you have the agent installed in W10. In this way determine if it is a host issue or if the guest has simply froze. If the guest interface has froze and the guest is still alive, the graphic driver could be the issue. I've seen some recent issues with QXL video, so maybe change the vm's video type - disregard performance differences and assess graphics stability. This may get you into a degraded, but stable desktop to at least check things within the guest.

If downgrading the host returned the guest to operation, then the recent logs within the guest should be attainable. The host journal may show errors, grep for qxl and vdagent which may show issue, if in use.

[hknox]

In virt-managers viewer window, under details, there is a the performance view where you can see if the vm is alive. You could send keystrokes to the vm, like Ctrl-Alt-Delete, and check if the host can pause, resume, shutdown and generally communicate with the vm assuming you have the agent installed in W10. In this way determine if it is a host issue or if the guest has simply froze. If the guest interface has froze and the guest is still alive, the graphic driver could be the issue. I've seen some recent issues with QXL video, so maybe change the vm's video type - disregard performance differences and assess graphics stability. This may get you into a degraded, but stable desktop to at least check things within the guest.

If downgrading the host returned the guest to operation, then the recent logs within the guest should be attainable. The host journal may show errors, grep for qxl and vdagent which may show issue, if in use.

Thanks for the suggestion about modifying the graphic drive, I'll give that a shot. In the meantime, downgrading to the QEMU package before the current one fixed the problem so it's something in the updated package. I've filed a bug report and will follow up there.
Hank

[hknox]

In case anyone ever runs into this issue, I found a fix:

Changing the Video driver in the VM to Virtio (I had it set to QXL) solved the issue, at the cost of a small performance hit.

However I found a better fix: I downloaded a more recent version of the Windows virtio drivers, virtio-win-0.1.252.iso, added it as a CD drive to the VM, fired up Windows (using the virtio Video device), installed virtio-win-x64.msi and ran virtio-win-guest-tools.exe, closed Windows, set the video driver back to QXL, rebooted and voilà, everything works as expected, no more freezing.

Thanks to everyone for suggestions.

[ChairmanFaust]

I can add to this as I have been experiencing this issue as well. I thought it was due to having two 4k displays in my VM but it does seem to be related to windows scaling. 125% is too small for me to read so I need 150% and after a random amount of time the screen locks up. It still pings but is unresponsive via the display. This seems like a problem with the windows guest drivers. I've even built a windows 11 VM from scratch and still have this problem. I'm not really sure where the best place to go with this as it seems to clearly be a qemu/kvm/qxl problem.

Code: Select all

<video>
  <model type="qxl" ram="131072" vram="65536" vgamem="32768" heads="2" primary="yes"/>
  <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>

video>
  <model type="qxl" ram="131072" vram="65536" vgamem="32768" heads="2"/>
  <address type="pci" domain="0x0000" bus="0x10" slot="0x02" function="0x0"/>
</video>

[hknox]

A couple of things:

Updating the Windows virtio drivers only seemingly fixed the issue: the next time I booted the VM using the QXL video driver, it started freezing again.

Using the updated QEMU Debian package, the only way to avoid the freezing is to use an alternate video driver; I used Virtio and it works well enough.

I worked with the Debian maintainer to find the commit where the freezing started. Reverting that change, rebuilding qemu-system-x86_64, and pointing the VM to that version fixed the freezing using the QXL driver. The Debian maintainer also pointed me to another patch (an alternative to reverting the offending commit) that also fixes the problem. (You can read all about this in the bug report pointed to above.)

Neither solution has been adopted in the Debian package yet, so either you have to use the Virtio video driver with the up-to-date Debian package, OR you have to build your own qemu-system-x86_64 and use that if you want the QXL driver.

[ChairmanFaust]

fantastic work! I would not have thought the issue to be with the qemu side but with the windows driver side. For me, I'm unable to use the VirtIO drivers as it kills my CPU and makes anything more than a webrowser stutter. I'll have to wait for the fix to go upstream before i can get it. What's funny is that I'm having this problem on my arch machine, i don't run qemu on my debian machine but its the same issue you're having so i commented. Rebuilt win10 and win11 it still occurs. I'm just surprised it isn't more widespread.

[rayzor]

It probably is more widespread its just difficult to search how to address this. Windows 11 qemu freeze is a common thing. I've been dealing with it in arch for a couple months now and finally got frustrated and dumped arch for debian thinking it might be a distro issue. Unfortunately, completely clean install of Windows11 in qemu, debian testing brand new install, and just like this post I can make it maybe 2 mins into a session in Windows 11 before it freezes.

Hopefully it is fixed soon, I know even a bleeding edge version like arch the fix wasn't in there today.

[stx8]

A couple of things:

Updating the Windows virtio drivers only seemingly fixed the issue: the next time I booted the VM using the QXL video driver, it started freezing again.

Using the updated QEMU Debian package, the only way to avoid the freezing is to use an alternate video driver; I used Virtio and it works well enough.

I worked with the Debian maintainer to find the commit where the freezing started. Reverting that change, rebuilding qemu-system-x86_64, and pointing the VM to that version fixed the freezing using the QXL driver. The Debian maintainer also pointed me to another patch (an alternative to reverting the offending commit) that also fixes the problem. (You can read all about this in the bug report pointed to above.)

Neither solution has been adopted in the Debian package yet, so either you have to use the Virtio video driver with the up-to-date Debian package, OR you have to build your own qemu-system-x86_64 and use that if you want the QXL driver.

Would you be able to provide anymore details such as which version it started having the issue on? And this one here might be a stretch but any rough guideline on how to repoint to a veroisn that works?

I also am more surprised this is not more wide spread...

[hknox]

I noticed the bug starting with Debian version 1:9.1.0+ds-8. The previous version, 1:9.0.2+ds-2+b1, works fine. You can get the earlier version from snapshot.debian.org. You have to add an archived repo to /etc/apt/sources.d/ by creating a file, snapshot-debian.list, and putting this line in it:

Code: Select all

deb [check-valid-until=no] https://snapshot.debian.org/archive/debian/20240916T205113Z trixie main

Then apt update.
apt-show-versions --all qemu-system-x86
should show that 1:9.0.2+ds-2+b1 is available. You need to downgrade several qemu packages, I used this command:

Code: Select all

aptitude install qemu-system=1:9.0.2+ds-2+b1 qemu-system-common=1:9.0.2+ds-2+b1 qemu-system-gui=1:9.0.2+ds-2+b1 qemu-utils=1:9.0.2+ds-2+b1 qemu-system-x86=1:9.0.2+ds-2+b1 qemu-system-misc=1:9.0.2+ds-2+b1 qemu-system-arm=1:9.0.2+ds-2+b1 qemu-system-mips=1:9.0.2+ds-2+b1 qemu-system-ppc=1:9.0.2+ds-2+b1 qemu-system-sparc=1:9.0.2+ds-2+b1 qemu-system-data=1:9.0.2+ds-2 qemu-utils=1:9.0.2+ds-2+b1 qemu-system-modules-opengl=1:9.0.2+ds-2+b1 qemu-block-extra=1:9.0.2+ds-2+b1 qemu-system-modules-spice=1:9.0.2+ds-2+b1

I hope that helps.

[ChairmanFaust]

It probably is more widespread its just difficult to search how to address this. Windows 11 qemu freeze is a common thing. I've been dealing with it in arch for a couple months now and finally got frustrated and dumped arch for debian thinking it might be a distro issue. Unfortunately, completely clean install of Windows11 in qemu, debian testing brand new install, and just like this post I can make it maybe 2 mins into a session in Windows 11 before it freezes.

Hopefully it is fixed soon, I know even a bleeding edge version like arch the fix wasn't in there today.

dude you saved me a ton of time... was going to do this... may do it anyway... arch has been a pain with random stuff breaking after every minor update... and other things not working as expected... kind of disappointing... that said i run Debian testing on a net top box b/c of driver issues and that just broke yesterday after an update... i hate windows but i have to give it credit for being more dependable

I noticed the bug starting with Debian version 1:9.1.0+ds-8. The previous version, 1:9.0.2+ds-2+b1, works fine. You can get the earlier version from snapshot.debian.org. You have to add an archived repo to /etc/apt/sources.d/ by creating a file, snapshot-debian.list, and putting this line in it:

id have to look this up for arch on how to do it... or maybe just go back to debian... i spend more time on "google -> tools -> results within the last year" than i do actually using my pc

[CwF]

i hate windows but i have to give it credit for being more dependable

IMHO, unless offline and solidified in concrete, upgraded versions are going to morph into a moving target.

[ChairmanFaust]

I noticed the bug starting with Debian version 1:9.1.0+ds-8. The previous version, 1:9.0.2+ds-2+b1, works fine. You can get the earlier version from snapshot.debian.org.

i just updated arch today, it grabbed qemu v9.1.2-1, the problem persists... win 11 locked up about a minute into use

IMHO, unless offline and solidified in concrete, upgraded versions are going to morph into a moving target.

I get that, I'm more upset that my windows 11 laptop is the most dependable system in my house... i really don't want that to be the case... trying hard to get away from MS products