Re: [libvirt PATCH v2 00/15] WIP/RFC: add QEMU "-display dbus" support
Hi
On Fri, Dec 3, 2021 at 8:29 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Thu, Dec 02, 2021 at 06:23:56PM +0400, marcandre.lureau(a)redhat.com wrote:
> From: Marc-André Lureau <marcandre.lureau(a)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...).
>
> 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.