0

I have a server running libvirtd with QEMU/KVM domains. I would like to access it with virt-manager from a remote machine, for which I open an SSH tunnel and forward a TCP port (libvirtd is listening on a local TCP port). Then, virt-manager is able to connect to the local socket with virt-manager -c qemu+tcp://host:port/system.

Unfortunately, virt-manager is not using its own connection for tunneling thru Spice/VNC sessions but tries to open new connections independently, to the socket opened by QEMU for each guest; it's bound to localhost so there's no luck. I'm able to get the port number with virsh domdisplay, tunnel it also via SSH, and use the viewer directly in the remote-viewer spice://host:port syntax to open the session manually.

It connects and then fails with:

(remote-viewer:16039): GSpice-WARNING **: 02:25:56.856: incomplete link header (-104/16)

What could this error possibly mean? What am I doing wrong here?
How do I connect properly to a remote QEMU Spice session thru an SSH tunnel?

While googling for the error, I found hints that this might possibly be related to TLS ports on the connection, whatever specifically this means. Trying to mitigate that, I've added defaultMode="insecure" to the <graphics/> element of the domain configuration, but this changed nother. Example QEMU domain XML:

<graphics type="spice" port="5995" autoport="no" listen="127.0.0.1" defaultMode="insecure">
  <listen type="address" />
</graphics>

UPD: I've tried several other things: started x11spice on the host and tried connected to that; also tried connecting from a Windows version of remote-viewer. Result: Linux version had the same "incomplete link header" error as when connecting to a VM guest; Windows version had a similar error, but the numbers in parentheses are different.

Which makes me wonder. Is SPICE able to connect when client and server are of different builds? Any known issues with that maybe?

hypersw
  • 101
  • 1
  • virt-manager (or virt-viewer) can handle URIs of type `qemu+ssh://` and create themselves the adequate SSH connection without having to configure manually any tunnel on the client. Why aren't you using this? – A.B Apr 18 '22 at 10:05
  • That would be a bit more complicated. The client machine is Win11 and keys are PuTTY format (so I tunnel with PLink), and virt-manager despite of being a Python app isn't ready to run on Win11. So I'm running it from within an Ubuntu VM for now, and it's using the socket opened on Win11 host. This could be arranged (like, convert keys, deliver to VM, run virt-manager and x11 in WSL, etc), but that's a totally another journey. – hypersw Apr 18 '22 at 11:55
  • The additional points are: (1) There seems to be no reason for `remote-viewer` not to work this way, probably some silly misconfig. I really wish I could understand that and have it sorted out. (2) In the end I mainly need `remote-viewer` and want to run it right on the Win11 host (there's an NT version of just that), where there will be no `virt-manager` at all (but `virsh` in an SSH session works good enough for its tasks, except for graphics). – hypersw Apr 18 '22 at 11:59
  • It's not clear if the solution exposes server services - not until it's found %) Maybe those are versions or settings or something else. The error is pretty unclear. No additional info in `--debug` either. – hypersw Apr 18 '22 at 12:01
  • Sorry I realize you were talking about remote-viewer (not virt-viewer) which doesn't have built-in ssh support. My bad. – A.B Apr 18 '22 at 12:02

0 Answers0