Yesterday, after regular system update my VMs suddenly stopped working
(initial configuration is based on EOS wiki article)
I can open, power on VM, it boots normally until login screen but as soon as I enter password and hit enter, both Virt Manager & VM windows just close. Reopening Virt Manager shows that VM is still running but attempt to open it once again, leads to the exactly same behavior described above.
Also, when this happens, I noticed that each time crossed mic icon briefly shows-up in Plasma system tray saying “virt-manager is using the microphone”.
This happens on both latest kernels - lts 6.6.13 and 6.7.1. Switching Video model and Display type under VM setting doesn’t help either.
Anyone else noticed something similar or have an idea where to start looking in order to troubleshoot it?
Checking both QEMU and Arch bug trackers, as well as Googling, doesn’t show recent reports with similar issue
journalctl shows these errors when VM crashes:
Jan 25 13:15:08 Serenity systemd-coredump[1580]: [🡕] Process 1395 (virt-manager) of user 1000 dumped core.
Jan 25 13:15:08 Serenity systemd[1]: systemd-coredump@0-1575-0.service: Deactivated successfully.
Jan 25 13:15:08 Serenity systemd[1]: systemd-coredump@0-1575-0.service: Consumed 2.042s CPU time.
Jan 25 13:15:08 Serenity kded5[816]: Service “:1.55” unregistered
Jan 25 13:15:08 Serenity virtqemud[1413]: libvirt version: 10.0.0
Jan 25 13:15:08 Serenity virtqemud[1413]: hostname: Serenity
Jan 25 13:15:08 Serenity virtqemud[1413]: End of file while reading data: Input/output error
My last update was on the 21st and all my VMs are running fine. What does paclog --after=2024-01-24 return? When checking pacseek -u, I didn’t see any packages directly related to qemu or libvirt.
As an addition: the more I’m “playing” with it - the more puzzling it becomes to pinpoint certain pattern.
Tried to create a new fresh Debian-based VM. Went through all graphical install process without any problems whatsoever. Afterwards, right at the end when it finished installation and made final reboot - VM crashed again. This time during systemd booting stage.
This is very strange. My 01-21 update included libvirtd, same version as yours. I’m also running the same linux-lts version. The only major difference is that my VMs are not using spice-vdagent for video (GPU pass-through instead).
If I have time later today, I’ll try installing another distro with spice.
Thanks for double-checking!
Can you please also share your config XML? (if it’s not all default)
In any case - looks like it’s just my particular system/setup not playing well with latest qemu. Will tinker with it a bit more and then just try my luck with virtualbox or vmware.
Just a small update:
created new vm with basically same settings (the only difference - by default it picked bios system instead of efi, so had to switch it) - no luck. Tried also Gnome Boxes to eliminate possible problems with Virt Manager, since it too uses qemu/libvirt under the hood - same vm crashes during boot.
At this point I’m giving up, cause I’m out of ideas. Granted, my 10y.o. system is quite old but from my understanding, if it is just a hardware incompatibility, I wouldn’t have been able to install guest or use it in a live mode at all
So… problem solved on its own. Kind of.
Turned out orc was the culprit. How on earth it managed to “fry” all my VMs is still a mystery, but I’ve been doing frequent updates lately, followed by tests, and after the last one when only orc & protobuf were updated, all VMs started to boot as usual.
I guess the main lesson is: update system once every 2 weeks and not on a weekly basis
Thanks a lot for your time and your willingness to help - I really appreciate it
Glad it’s working now, although I’m a little confused about protobuf. Mine hasn’t been updated since December; full update was run this morning (orc was updated).
Sorry for the confusion - I only mentioned this package in the context of my latest update itself. orc somehow messed whole thing up.
Some additional information I was able to track, in case you’re interested:
Probably this bug (which was closed earlier today):
I’m guessing you’re running an older Intel CPU? This bug was that the AVX backend was requiring AVX2, which was introduced around 10 years ago and so was not present in older CPUs.