After update yesterday: extreme lag

I’m running Manjaro XFCE in a VM. I’ve had this VM for ~1 year, installed all updates along the way, and never had any issues - until yesterday performance has been great. After the updates I installed yesterday, I’m experiencing extreme lag - 20-60 seconds between input and system response. It started with Firefox, but appears to be systemwide even when Firefox is not running. The weird thing is, when I run htop to see what might be causing the issue (60 sec to open terminal, another 30 secs to start htop…) - everything looks normal. Only about 600 MB RAM in use, and CPU usage near zero. And yet, something is causing the system to be unresponsive and slow to the point it’s unusable. Anyone have thoughts on what to check next?

And what is you host OS you run, and what virtualization software do you use?

have you checked in the log ?

sudo journalctl -b0 -p4

I’m using Boxes on Fedora 34. Granted, I did also just update to Fedora 34 last week - but I’ve used the Manjaro VM (and other VMs) since then with no issues.

My guess is there is something Video related between your host and guest, and depending what you use, there might be something that reset, or failed at some point, hence making all seem to have a lag.

I ran journalctl as suggested, and got a whole heap of kernel errors. Without pasting in everything, here are some of the errors in approximate order listed:

kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
kernel: TAA CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html for more detai>
systemd-xdg-autostart-generator[681]: Configuration file /etc/xdg/autostart/msm_notifier.desktop is marked executable. Please remove executable permission bit>
systemd[674]: -.slice: Failed to migrate controller cgroups from /user.slice/user-969.slice/user@969.service, ignoring: Permission denied
kernel: kauditd_printk_skb: 108 callbacks suppressed
lightdm[781]: gkr-pam: unable to locate daemon control file
kernel: f 4026531852#326: failed to wait on release * after spincount *
pulseaudio[987]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did >
pulseaudio[987]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did >
[TTM] Buffer eviction failed
kernel: qxl 0000:00:01.0: object_init failed for (8298496, 0x00000001)
[drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO

By far the most common error seems to be “kernel: f 4026531852#326: failed to wait on release * after spincount *” - it occurs many many times with different numbers where I put the asterisk.

Sounds feasible. But would that not then affect all guests? My other VMs are running fine…

This seems to be the issue. On Linux guests, the qxl and bochs_drm kernel modules must be loaded in order to gain a decent performance. Taken from arch wiki. Maybe that got affected somehow? Not very knowledgeable in Gnome Boxes, spices, qxl or votrio stuff, but maybe there is a hint for you in that regard.

Install virt-manager, open it. Under “QEMU/KVM User Session” double click on your archlinux vm, then click on the light bulb icon, under Video QXL change QXL to virtio.

1 Like

virt-manage does not see VMs created in Gnome Boxes. However, I discovered that Gnome Boxes will let me edit the xml. I found the only instance of qxl in the file here:

/sound video
model type=“qxl” ram=“65536” vram=“65536” vgamem=“16384”

However, when I change qxl to virtio there is an error about the ram configuration only being supported by qxl. So it seems I can’t just change qxl to virtio, I would also need to change the ram parameters that follow it…