Re: [libvirt PATCH v2 00/15] WIP/RFC: add QEMU "-display dbus" support
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 ?
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.
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 ?
Of course we would actually need the dbus clients to exist first...
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|