Bug 1859377
| Summary: | virt-manager deadlock on kubuntu 20.04 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Chris Bertin <chris.bertin> | ||||
| Component: | virt-manager | Assignee: | Cole Robinson <crobinso> | ||||
| Status: | CLOSED DEFERRED | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | unspecified | CC: | berrange, crobinso, gscrivan, mhicks | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-09-16 21:07:32 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Thanks for the report. This is likely a libvirt bug. What libvirt version are you using? Do you have a way to upgrade to see if it reproduces with a newer libvirt version? Hi Cole, this is the version that comes with Kubuntu 20.04: $ virsh version Compiled against library: libvirt 6.0.0 Using library: libvirt 6.0.0 Using API: QEMU 6.0.0 Running hypervisor: QEMU 4.2.0 I have not seen the deadlock in a few days but it can take minutes for the VM window to refresh when I open my laptop in the morning. It used to come up right away, on 18.04 and all previous Kubuntu releases I have used. Not sure what libvirt version was on my system previously. Okay thanks for the info. Please let me know if you can trigger it again. So this happens after closing your laptop (suspend to ram) and waking it after a period of time? Also, is the libvirt-guests service enabled? sudo systemctl status libvirt-guests Yes, it happens after suspending to ram.
Here is the output of the systemctl command:
libvirt-guests.service - Suspend/Resume Running libvirt Guests
Loaded: loaded (/lib/systemd/system/libvirt-guests.service; enabled; vendor preset: enabled)
Active: active (exited) since Mon 2020-08-31 08:18:45 PDT; 8h ago
Docs: man:libvirtd(8)
https://libvirt.org
Process: 1622 ExecStart=/usr/lib/libvirt/libvirt-guests.sh start (code=exited, status=0/SUCCESS)
Main PID: 1622 (code=exited, status=0/SUCCESS)
Aug 31 08:18:45 chrisblx systemd[1]: Starting Suspend/Resume Running libvirt Guests...
Aug 31 08:18:45 chrisblx systemd[1]: Finished Suspend/Resume Running libvirt Guests.
Thanks for looking into this. Am I the only one reporting this issue?
> Thanks for looking into this. Am I the only one reporting this issue?
That I know of, yes. But maybe there's issues in ubuntus tracker or libvirt tracker.
ubuntu enables that service by default IIRC but for example Fedora doesn't so it could be something triggered by using that service
What it probably means is that the VM process is hanging for some period of time after your host restarts, and an operation
virt-manager requests is timing out. There have been a lot of issues over the years with qemu processes behaving weirdly
after host suspend resume so it's not too surprising.
FWIW if I had to guess it's not a virt-manager issue specifically, the app isn't doing anything special here, just occasionally
polling for stats data. My guess is this issue triggers when you suspend the machine when virt-manager is in the middle of an
operation, and something between libvirt and the VM hangs enough to trigger the timeout. Or maybe the timeout logic gets confused
because host time suddenly jumped forward
Upstream virt-manager is stopping use of bugzilla.redhat.com for issues, in favor of the github issue tracker https://github.com/virt-manager/virt-manager I don't think this issue is anything virt-manager can fix itself, I suspect it's some weird interaction between libvirt+qemu and host suspend. I suggest filing this bug with your distro against libvirt, maybe you'll find other hits there where libvirt-guests.service is enabled by default I'm closing this. But if signs point back to virt-manager as the culprit please file a github issue and we can continue the discussion |
Created attachment 1701998 [details] deadlock message Description of problem: After console has been idle for a while (typically overnight), window is frozen. No response to pause or any other command. After several minutes, and after closing the console window and re-opening it, the attached message shows up. The VM itself is still alive and not in a hang state so I assume the problem comes from virt-manager (or perhaps KDE?). Version-Release number of selected component (if applicable): virt-manager 2.2.1 How reproducible: Every day Steps to Reproduce: 1. Create a [windows?] VM 2. Open the console 3. Leave the system idle overnight Actual results: Console is frozen (doesn't respond) Expected results: Console should not freeze. This has been working flawlessly since Kubuntu 14.04 Additional info: