I’ve been using looking glass and everything has been quite stable on Ubuntu 20.08. Having interest in using the new virtio-fs driver to improve my vm performance, today I updated my workstation from focal to groovy (20.10). The update went fine except for looking-glass.
As expected, the client wouldn’t run due to linkage to the host OS so I pulled the latest version from master and rebuilt the client & downloaded the matching frame server without problem.
As usual, I assigned a 2nd keyboard & mouse, booted the gpu vm, switched monitor inputs, and was able to access the vm via direct monitor connection with no problem. I then updated virtio in the vm to 1.189 (latest), installed the new frame server (latest bleeding edge), rebooted the vm and was then able to access it via the looking-glass clientas expected.
Then the problems began. Symptoms:
The spice mouse, which worked fine before, now randomly jumps around the screen when I move it, both when using both looking-glass and directly connected. Assigned mouse & keyboard and the spice keyboard work.
After about a minute or two after starting & using the looking-glass vm, the all of the vms running (including non-looking-glass vms) appear to hang. This seems to be looking-glass related since other non-looking-glass vms are stable until I start the looking-glass frame server vm. Even after forcing shudown of the vms and restarting them, I can’t access them. I have to reboot the host to get the vms running again. So it looks like something is getting wedged in the qemu host. (?)
Random thoughts & ideas on what might be causing my issues:
running bleeding-edge from master? Is this a known issue? Skimming changes from master to b2rc4 nothing jumps out as a major change.
virtio v189. It’s ‘latest’ but been around for a while. What version should I be on, v185?
I notice that IVSHMEM is still v181 and quite out of date. I can’t find a newer version for windows.
Any thoughts or suggestions? Are other looking-glass users having success or failure on 20.10?
I’m going to try a few things tonight; hopefully I won’t be forced to roll back 20.08 tomorrow night so I can get work done on Monday.
Jumping mouse is a known issue, the exact cause is yet to be determined as it doesn’t affect all. Only suggestion I have is to ensure you have mouse acceleration disabled in windows as per the LG FAQ.
There is nothing in LG that can cause what you describe. You have a larger issue at hand that perhaps LG Is exposing, but I can say for certain that LG is not the cause.
I agree it’s likely to be something latent that’s being triggered by LG not LG itself.
In the BIOS I changed a PCIe power management setting and now the gpu-passthru vm appears more stable, but it’s only been running for about 10 minutes. Definitely an improvement.
I realized the jumping mouse issue was only happening in uncaptured mode. I had a script that pushed a scroll-lock keystroke into the viewer window after it starts but that’s apparently been blocked and that triggered the issue at least in part. Using the new spice:captureOnStart setting works except I seem to be seeing the wrong-extents (invisible wall) issue reappear. But toggling scroll-lock a few times isn’t a big deal, at least it’s looking like I won’t have to roll back the OS which is a relief.
This is a bit anecdotal but might have a few useful clues:
Unfortunately I was forced to rollback restore to Ubuntu 20.08. I was able to improve stability some but the freeze still reliably occurred when under heavy IVSHMEM load for some reason. No matter what I did, playing back a video in the LG VM while also playing a video in a spice VM would trigger the problem within a few minutes. After rolling the machine back it’s 100% stable again no matter what’s thrown at it. So it’s looking like a Ubuntu 20.10 (QEMU 5.0) bug.
But I noticed a few things while troubleshooting that might be helpful.
Jumping mouse: Before rolling back the host I rolled back the VM images & configurations, then for viewer compatibility in the LG VM I upgraded the frameserver to bleeding-edge. So at that point I was running virtio-win guest tools v1.173 in the VM with the latest version of LG. I noticed the jumping mouse cursor problem went away regardless of whether capture was enabled or disabled. This implies the problem might be related to virtio-win versions newer then v1.173. Maybe taking a look at the revision history might lead to finding the mouse issue?
Semi-related: I seem to prefer B1 over later builds because frame refresh behavior is different. B2 builds are much smoother in video playback & 3D animation but on this machine refresh is visibly choppy when animating 2D GDI operations - things like dragging a window around or scrolling text in a window are still laggy & choppy. B1 has the opposite behavior - 2D animation is smooth yet 3D is choppy. For me, I’m doing a lot of software development (text scrolling, etc) and 3D a little less often so B1 is less irritating. Yes, I’m still on Intel integrated graphics on the host (no free PCIe lanes for another video adapter on this motherboard) and that’s a bottleneck but perhaps integrating whatever made B1 better for 2D with B2 might improve LG to the point where it works acceptably in all scenarios including with an integrated graphics host adapter? I think that’s the low-hanging fruit for LG: using integrated graphics for host display + GPU for 3D in a VM means guys wouldn’t need to stuff two video cards in their machine, making the whole thing potentially a lot more turn-key & easy to set up & configure. I.e. a lot more mainstream machines could run it.
Good observation, I will update my virtio-win today and see if I can replicate the issue.
The new frame behaviour ensures we are only drawing when there are new frames and allows for some drift, you can replicate the old behaviour though by setting the minimum frame rate to 2x your desktop frame rate. Windows bypasses vsync when dragging windows, etc, which can push hundreds of FPS which is likely the issue you’re having. Perhaps we need a max FPS option too for lower end GPUs.
I have dug a bit through the code and spotted an error with the re-sync for frame timing, this has been fixed in bleeding edge. As for the fps limit, I forgot that you can turn off the mouse triggered redraws which reverts it to the prior behaviour of only drawing the frames as they come in.
Give: input:mouseRedraw=no a try.
Edit: in fact I see more issues here still, I am investigating