Hi
On Tue, Mar 11, 2025 at 5:28 PM Martin Kletzander <mkletzan@xxxxxxxxxx> wrote:
> 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
How does it fail? (it works on my end)
> <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.
Not sure what is the best wording, but I understand it is confusing.
It requires a "D-Bus bus" to work. (we could make it work with p2p
too, eventually, but that might make multi-process handling more
complicated in the future - say if vhost-user-gpu exports the dbus
display interface etc)
>
> 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).
Are you saying that libvirt should check the presence of certificates
before running qemu-rdp and provide an early error?
qemu rdp log is explicit (Error: reading server cert `...`). However,
I admit libvirt error report isn't great, as it fails with "The name
org.QemuDisplay.RDP was not provided by any .service files". I will
look into improving that.
> 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
>
If you run it manually, make sure you set the credentials before
connecting the client, ex:
busctl --user call org.QemuDisplay.RDP /org/qemu_display/rdp
org.QemuDisplay.RDP SetCredentials sss user pass ''
> ===
>
> 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.
Thanks a lot for testing and the suggestions!
