I have been seeing this for a while in the last months. KDE VM seems to hang hard after a while idle. It completely locks and can only be hard reset. Reproducible: Always Steps to Reproduce: 1. Boot current Fedora 39 (or Rawhide) KDE Plasma Live image in virt-manager 2. Leave the liveuser session running idle for some time (maybe ~10min +-). 3. Actual Results: System seems to hang with console cursor showing in top left corner. Expected Results: No hang expected
Some tests I made on this: 1- This only happens on the publically released F38 iso (https://download.fedoraproject.org/pub/fedora/linux/releases/38/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-38-1.6.iso) but does not happen on the August respin iso, which leads me to think it got fixed since release. 2- The way I tested this is to download the publically released f38 iso, and adding it in a VM in virt-manager. Not sure it matters, but I gave it 8gb of ram and 80gb hard drive. 3- To repro this, you don't even need to install fedora, simply boot the livecd and let it sit on the desktop for 20-30minutes. It'll go to sleep and never come back. (Screen will show that the graphical console has been disconnected, but the VM is still running)
Just for additional clarification, on the public f38 iso, once it goes to sleep, you wont be able to bring it back. Move the mouse over the VM window, press keys, try to bring up other TTYs, nothing will work. On the respin livecd, once it goes to sleep, it'll come back just by moving the mouse over the window (as expected).
Nevermind, it happens on the f38 respin iso too. Basically, launch the live cd, and go in power management settings. Change the "Suspend the system after 15 minutes" to 1 minute and wait. I waited 2-3 minutes and the screen was frozen solid.
After some testing we found that it is something related to the VM video drivers at virt-manager: => virtio (default) -> freeze => virtio (with 3d acceleration enabled and openGL) -> freeze => VGA -> returns ok from sleep => QXL -> returns ok from sleep This behavior is consistent both on live sessions VMs and installed system VMs, and both release gold iso (Fedora-KDE-Live-x86_64-38-1.6.iso) and last respin tested (F38-KDE-x86_64-LIVE-20230816.iso) All VMs where UEFI I tested too a live USB made with Fedora-KDE-Live-x86_64-38-1.6.iso runing a live session on my notebook, baremetal, and it returned from sleep three times, without errors, just pressing the return key on keyboard (it doesn't wake with mouse clicks, only pressing the return key, wich I think is expected behaviour)
BTW booting a Fedora 38 Workstation iso (Latest respin) also has this freezing behavior. No freezing with VGA here either so it seems to be related to the virtio driver and likely not DE specific.
Good observations, moving this to qemu
Though it would be better if KDE didn't autosuspend in a VM I guess. I _think_ GNOME inhibits autosuspend in a VM.
In fact F39 WS doesn't seem to suspend at all for me.
You can trigger the issue without waiting for the DE with: sudo systemctl suspend
Here some background on this, and why it's different at gnome https://bugzilla.redhat.com/show_bug.cgi?id=2180047
I also opened bug 2232711 to track disabling VM auto-suspend in KDE, like GNOME 45 seems to do.
Proposed as a Blocker and Freeze Exception for 39-beta by Fedora user geraldosimiao using the blocker tracking app because: This happens on KDE spin, wich is a blocker release, and its a violation of Beta criterion "The release must be able host virtual guest instances of the same release", on the basis that VMs which auto-suspend after 15 minutes and cannot be resumed are not really working.
Bug confirmed on last F39 KDE build: Fedora-KDE-Live-x86_64-39-20230817.n.0.iso
Hmm this is a bit confusing to me. virt-install/virt-manager and boxes all configure the VM to disable hardware s3/s4 support, but apparently that isn't trickling up the OS. There was some weirdness 8 years ago but I thought that was resolved (some context https://bugzilla.redhat.com/show_bug.cgi?id=1223541#c13 ) https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/736 says that gnome has an explicit workaround disabling autosuspend for VMs. I just reproduced with the f38 kde iso like described above. When the VM suspends like this, it isn't even communicated up the virt stack, so libvirt still sees the VM was 'running' and not 'pmsuspended'. Weird. elmarco, any idea why VGA and QXL video would trigger a VM wakeup here, but not virtio video?
suspend/resume is broken with virtio-gpu(s). It will reset the virtio device (free all resources etc), but nothing is implemented in the Linux driver to restore it. (virtio_gpu_driver.feeze/restore)
See also https://lore.kernel.org/lkml/20230720115805.8206-1-Jiqian.Chen@amd.com/
Thanks Marc-Andre! Relatedly, do you know why linux is advertising `mem` in `/sys/power/state` when we are disabling s3/s4 support on qemu cli? With -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 for q35 case. CC kraxel
+3 in https://pagure.io/fedora-qa/blocker-review/issue/1178 , marking accepted blocker. Note, we would accept some kind of workaround for this (e.g. disabling the 15 minute auto-suspend on VMs) - it doesn't need to be fully 'fixed' such that suspend works, necessarily.
Not sure how easy this bug is to fix? Certainly a fix would be most welcome: since it affects (accidental) manual suspend in any VM desktop I think. Another workaround would be to not use virtio by default, though I don't know if that is practical? Bug 2232711 is the corresponding KDE bug about auto-suspend. I was wondering if making the KDE bug a blocker might be more realistic? Though someone would have to implement the VM detection.
Hmm, yeah, agreed. Let's propose the other as a blocker and re-vote this one.
-5 in https://pagure.io/fedora-qa/blocker-review/issue/1178 , marking rejected. The other bug will be accepted.
Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26. Fedora Linux 39 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.