Re: [PATCH 18/19] qemu: add RDP support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

On Wed, Jan 29, 2025 at 7:25 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
>
> On Wed, Jan 29, 2025 at 05:40:40PM +0400, marcandre.lureau@xxxxxxxxxx wrote:
> > From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx>
> >
> > Wire the external server RDP support with QEMU.
> >
> > Check the configuration, allocate a port, start the process
> > and set the credentials.
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx>
> > ---
> >  docs/formatdomain.rst     |  25 ++++--
> >  src/conf/domain_conf.h    |   1 +
> >  src/qemu/qemu_extdevice.c |  46 +++++++++--
> >  src/qemu/qemu_hotplug.c   |  49 ++++++++++-
> >  src/qemu/qemu_hotplug.h   |   1 +
> >  src/qemu/qemu_process.c   | 167 ++++++++++++++++++++++++++++++++++----
> >  6 files changed, 257 insertions(+), 32 deletions(-)
>
>
> > +            if (!virDomainDefHasDBus(vm->def, false)) {
> > +                virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> > +                               _("qemu-rdp support requires a D-Bus bus graphics device."));
> > +                return -1;
> > +            }
>
> IMHO this is not the correct way to model it.
>
> Use of DBus is an internal impl detail of the RDP backend that is
> being configured. Users shouldn't have to know that - they should
> just be able to request 'RDP' alone for the <graphics> type.
>
> Consider if we wanted to provide a non-integrated VNC server for
> QEMU. We wouldn't do that by requiring use of a <graphics type=dbus>
> alongside the <graphics type=vnc>, as that config has the distinct
> meaning of requiring VNC and DBus in parallel.
>
> Where we have a choice of underlying implementations, we would
> typically have something like a <backend type="qemu|dbus"/>
> as a child element to select between them.

I wish it would be an implementation detail. Unfortunately, the qemu
devices needs to be configured to export themself on dbus too
(chardev/usb/audio), this is also exposed on the domain XML. For the
most simple case, ie display only, we could probably hide the dbus
implementation detail. But in general, we probably better be explicit
about it. Being explicit would also avoid surprises when checking the
list of available displays (think domdisplay --all, or by inspecting
the bus). I am not sure it's worth trying to hide it (for ex, should
<redirdev bus='usb'> be exposed on dbus by default when dbus or rdp is
enabled?). If people feel it's really best, I can give it a try, but I
fear it's going to be more struggle and surprises without much
benefit.




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux