Hi On Tue, Mar 11, 2025 at 5:28 PM Martin Kletzander <mkletzan@redhat.com> 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!