virt-gtk: experimental alternative to virt-manager (better perf but worse sandboxing)

Hi!

I’m hesitant to post this here since security downgrades aren’t really desirable in the Whonix community, but perhaps people will find it interesting nevertheless.

At least on my system (Debian Bookworm host on ppc64le), virt-manager has terrible input/video latency (often well over a second of lag) and nonfunctional audio. As best I can tell, a large part of the problem is that it’s piping the framebuffer through a SPICE socket rather than simply using shared memory like Qubes does. I figured that maybe a cheap-and-easy workaround would be to write a wrapper that generates a QEMU command from a libvirt VM configuration, and tweaks the QEMU command to show a standard GTK GUI without using SPICE. So, a few evenings later, I had a working proof of concept:

Sandboxing is kind of nonexistent at the moment (I’d like to fix that!), and the code quality isn’t great (parsing XML with Bash is a bad idea, I’d like to replace it with an actual XML parser). But, it only took me a few evenings, and It Works On My Machine ™. So I figured I’d share it here in case anyone might find it interesting. PR’s very welcome. It certainly is much less stressful to use than virt-manager (at least if you’re stressed by latency like I am).

(Wasn’t sure if this should go in the KVM or Development category, feel free to move to Development if you think it’s better suited there.)

Cheers!

3 Likes

Interesting! Thanks Jeremy for sharing this. Yeah it’s OK to post it here.

2 Likes

No worries at all. This is explicitly allowed No Intentional User Freedom Restrictions. Many users have many different use cases. We can document the facts, can tell users “increases attack surface” but if a user needs certain functionality, we don’t stay in the way. Also related: Kicksecure Tuning

The closest related thing to unwanted would be unsolicited recommendations of non-freedom applications as per Whonix Policy On Non-Freedom Software but nobody was doing that.

I suppose 3D Graphics Acceleration was not an option in your case?

1 Like

That’s correct; my machine uses an unaccelerated 2D framebuffer GPU (AST2500), so OpenGL is provided by LLVMpipe. Enabling OpenGL in the virtio guest GPU causes the VM to fail to boot with the error opengl is not available; enabling OpenGL in the SPICE backend causes the VM to fail to boot with the error No DRM render nodes available. (Your guess is as good as mine why it doesn’t even boot with LLVMpipe, but even if it did boot, I’d expect LLVMpipe to make it less performant, not more.)

I just managed to improve the sandboxing a bit; QEMU no longer runs as root. It still has way more privs than I wish it did, but gotta start somewhere.

1 Like

Improved the sandboxing situation again (QEMU no longer runs with cap_net_admin), and in the process, I found a much better way to sandbox QEMU than the QEMU wiki documents. (QEMU wiki says to use setuid; gross… setcap works fine for this and is much safer.) I guess I should probably contact the QEMU devs about maybe improving their docs.

This is still not as well-sandboxed as virt-manager, but it’s a hell of a lot less scary than the initial version was.

2 Likes

Does it run without the need to dnsmasq as well?

Having issue with virt-manager that it doesnt run without dnsmasq-base package (debian):

1 Like

I haven’t tried, but virt-gtk uses virsh, so based on the thread you linked, my guess is that since virsh won’t work under that condition, virt-gtk probably won’t either. Feel free to try and let me know, I like good surprises. :slight_smile:

1 Like

Im not sure i got the software correctly, it doesnt has GUI just a CLI? what are the dependencies/packages needed before running it?

Can you import plain debian, or kicksecure or whonix as a demonstration setup?

Not sure if its useful or not but this is a GUI Qt5-based manager can take some features/experiments from (development looks stalled).

1 Like