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?

Improve this question
5
  • 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, 2022 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, 2022 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, 2022 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, 2022 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, 2022 at 12:02

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.