4:27 p.m.
On Fri, Mar 07, 2025 at 04:22:46PM +0100, Martin Kletzander wrote:
On Tue, Feb 18, 2025 at 02:16:05PM +0400, marcandre.lureau(a)redhat.com
wrote:
>From: Marc-André Lureau <marcandre.lureau(a)redhat.com>
>
>Hi,
>
>This patch series offers an out-of-process Remote Desktop Protocol (RDP)
>server solution utilizing QEMU's -display dbus interface, offering improved
>modularity and potential security benefits compared to built-in server.
>
>This initiative was spearheaded by Mihnea Buzatu during the QEMU Summer of Code
>2023. The project's goal was to develop an out-of-process RDP server using the
>-display dbus interface, implemented in Rust. Given that the IronRDP crate
>lacked some server support at the time, investments in IronRDP were required.
>
>I finally released an initial v0.1 version of qemu-rdp on crates.io
>(https://crates.io/crates/qemu-rdp). That should allow more people to review and
>evaluate the state of this work.
>
>On unix systems, with cargo/rust toolchain installed, it should be as easy as
>running "cargo install qemu-rdp", apply this patch series for libvirt, set
the
>"rdp_tls_x509_cert_dir" location for your TLS certificates, and configure a
VM
>with both dbus & rdp graphics (run "virsh domdisplay DOMAIN" to get the
display
>connection details).
>
>Thanks for the reviews & feedback!
>
>v2: thanks to Daniel review
>- drop extra error report from "qemu: report an error for unsupported
graphics"
>- replace g_return pre-conditions with ATTRIBUTE_NONNULL
>- improve "qemu/dbus: keep a connection to the VM D-Bus" to also reconnect
>- use domainLogContext for logging (for virtiofs as well)
>- check for qemu-rdp availabilty for setting 'rdp' capability
>- make dbus-addr qemu-rdp capability mandatory
>- rebased
>- add r-b tags
>
>Marc-André Lureau (21):
> build-sys: drop -Winline when optimization=g
> build: fix -Werror=maybe-uninitialized
> qemu-slirp: drop unneeded check for OOM
> util: annotate non-null arguments for virGDBusCallMethod()
> qemu: fall-through for unsupported graphics
> qemu: add rdp state directory
> qemu: add qemu RDP configuration
> conf: parse optional RDP username & password
> conf: generalize virDomainDefHasSpiceGraphics
> qemu: use virDomainDefHasGraphics
> qemu: add RDP ports range allocator
> qemu: limit to one <graphics type='rdp'>
> qemu/virtiofs: use domainLogContext
> qemu/dbus: keep a connection to the VM D-Bus
> qemu/dbus: log daemon stdout/err, use domainLogContext
> qemu: validate RDP configuration
> qemu: add qemu-rdp helper unit
> qemu: pass virQEMUDriverConfig to capabilities
> qemu: add 'rdp' capability if qemu-rdp is available
> qemu: add RDP support
> tests: add qemu <graphics type='rdp'/> test
Without testing it (yet, I want to try it next week), without deep
knowledge of D-Bus details and ideally with the teeny tiny details
adjusted:
Reviewed-by: Martin Kletzander <mkletzan(a)redhat.com>
So I tried testing it and I found a couple of issues. Those might be on
my side, maybe caused by misunderstanding of it all. First of all
<graphics type='dbus'/> fails with these patches for me even without
<graphics type='rdp'/>. That might be the source of all other issues,
but since I was not sure whether to use p2p='yes' or
address='unix:path=...' I tried both. When address is specified qemu
tries to connect to it, so that's not the right approach. When I
specify p2p='yes' then the VM starts. If I add the RDP graphics I get a
"confusing" error message:
error: unsupported configuration: qemu-rdp support requires a D-Bus bus
graphics device.
which should probably say "qemu-rdp support requires a non-p2p dbus
graphics device" instead since it is looking for a p2p='no' dbus
graphics.
If I delay the checking of qemu-rdp running I find out that it fails
right away. It cannot connect to the unix socket, so I tried just
running qemu VM with dbus graphics and qemu-rdp manually, but that
failed on the missing certificate files. That could be checked before
blindly passing it down to the helper, too (even though I was running it
manually this time it reminded me of that possibility).
Ideally some handshake could confirm it is actually running. If not a
handshake, then maybe waiting whether it listens on where it is supposed
to or some other indication of it being started while checking that the
PID exists, so that it is not a dumb delay.
Even running it manually I cannot verify it works, but that's probably a
client-side issue?
Server output when trying rdesktop:
Waiting for org.qemu...
Starting RDP server, args: ServerArgs { bind_address: 0.0.0.0:3389, cert: None, key: None,
remotefx: Disable }
Cert: "/home/nert/.config/qemu-rdp/server-cert.pem", Key:
"/home/nert/.config/qemu-rdp/server-key.pem"
2025-03-11T13:21:00.350891Z ERROR ironrdp_server::server: Connection error error=[no
credentials while doing credssp] general error
2025-03-11T13:21:00.352401Z ERROR ironrdp_server::server: Connection error
error=accept_begin failed
Caused by:
[failed to negotiate security protocol] general error
sdl-freerdp client output (no error on the server side reported):
[14:24:35:046] [449399:0006db7b] [ERROR][com.freerdp.core.transport] -
[transport_default_write]: BIO_should_retry returned a system error 32: Broken pipe
rdesktop client output:
Failed to initialize NLA, do you have correct Kerberos TGT initialized ?
Core(error): rcp_recv(), connection closed by peer
===
Anyway, I'm clearly doing something wrong, but there are some issues in
the code as well and from the greater picture it should not be this
complicated to test it out, should it? I can test out other patches
from you if you want, and I am open to hearing tips on what I'm doing
wrong.
Have a nice day,
Martin