Score:0

virt-manager's remote-viewer: fails to connect thru SSH tunnel with "incomplete link header (-104/16)

ne flag

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?

A.B avatar
cl flag
A.B
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?
ne flag
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.
ne flag
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).
ne flag
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.
A.B avatar
cl flag
A.B
Sorry I realize you were talking about remote-viewer (not virt-viewer) which doesn't have built-in ssh support. My bad.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.