On Thu, Mar 13, 2025 at 11:59:41AM +0400, Marc-André Lureau wrote:
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 withoutHow does it fail? (it works on my end)
$ virsh dumpxml fedora39 --xpath //graphics <graphics type="dbus"/> <graphics type="spice" autoport="yes"> <listen type="address"/> <image compression="off"/> </graphics> $ virsh version Compiled against library: libvirt 11.1.0 Using library: libvirt 11.1.0 Using API: QEMU 11.1.0 Running hypervisor: QEMU 9.2.2 $ virsh start fedora39 Domain 'fedora39' started $ virsh destroy fedora39 Domain 'fedora39' destroyed $ echo 'Start daemon with patches' Start daemon with patches $ virsh version Compiled against library: libvirt 11.1.0 Using library: libvirt 11.1.0 Using API: QEMU 11.1.0 Running hypervisor: QEMU 9.2.2 $ # Same version, but this time with the patch series applied $ virsh dumpxml fedora39 --xpath //graphics <graphics type="dbus"/> <graphics type="spice" autoport="yes"> <listen type="address"/> <image compression="off"/> </graphics> $ virsh start fedora39 error: Failed to start domain 'fedora39' error: operation failed: Failed to connect to dbus-daemon: The connection is closed
<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)
No matter how, but mentioning that it must not be p2p would help.
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.
Thanks. I haven't encountered the certificate issue, as I generated the certificated before I noticed that we're passing it blindly. But if the error gets spat out correctly, then that's fine, I guess.
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 peerIf 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 ''
That's not mentioned in https://crates.io/crates/qemu-rdp =D =D =D
=== 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!
You're welcome, thanks for taking the feedback, I'll gladly test next versions.
Attachment:
signature.asc
Description: PGP signature
