Hi
On Tue, Mar 11, 2025 at 5:28 PM Martin Kletzander <mkletzan(a)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!