Hi On Fri, Dec 3, 2021 at 8:29 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Thu, Dec 02, 2021 at 06:23:56PM +0400, marcandre.lureau@redhat.com wrote:
From: Marc-André Lureau <marcandre.lureau@redhat.com>
Hi,
This series implements supports for the upcoming QEMU "-display dbus" support. Development is still in progress, but I hope to land the QEMU support early in 6.3 (last version posted: https://patchew.org/QEMU/20211009210838.2219430-1-marcandre.lureau@redhat.co...).
By default, libvirt will start a private VM bus (sharing and reusing the existing "vmstate" VM bus & code).
The feature set should cover the needs to replace Spice as local client of choice, including 3daccel/dmabuf, audio, clipboard sharing, usb redirection, and arbitrary chardev/channels (for serial etc).
The test Gtk4 client is also in progress, currently in development at https://gitlab.com/marcandre.lureau/qemu-display/. A few dependencies, such as zbus, require an upcoming release. virt-viewer & boxes will need a port to Gtk4 to make use of the shared widget.
How is this intended to work permissions wise ?
For the qemu:///session instance, everything is running the same user account, so its fairly easy.
For the qemu:///system instance, the VM's private dbus-daemon bus will be running under a qemu:qemu user account, while the user wishing to have a client window will be a completely different account. How will the Gtk4 client get permission to connect to dbus-daemon ?
Tbh, I haven't tried system instance yet! The per-vm bus needs to allow user connections (just like the dbus system bus). I'll add this to my todo/tocheck list for the next iteration.
Also what are the long term implications for the rest of the QEMU builtin display backends ?
It feels like all of VNC, SPICE, SDL and GTK backends that are currently run in the main QEMU process, could be split off to be separate programs using dbus.
Yes, I even started a VNC server (https://gitlab.com/marcandre.lureau/qemu-display/-/tree/master/qemu-vnc), although it's really a toy compared to qemu implementation at this point. I would rather focus on an RDP server though.
Libvirt currently represents each fo these backenjds as a <graphics> type, and I think we'd want to continue to use that syntax even if they were separate processes.
ie, i would want something more like
<graphics type="spice"> <backend type="builtin|dbus"/> </graphics>
to request that libvirt spawn a SPICE server, connecting over dbus vs built-in. Likewise for the other options.
IOW, do we actually want to expose type="dbus" as a concept long term, or are we better off just having it as an internal impl detail ?
If we can make it an internal impl detail, that would be great (like we did for slirp-helper - even if nobody really uses it ;)
Of course we would actually need the dbus clients to exist first...
Yes, it will take a while to get there.