[virt-tools-list] [Spice-devel] Feature requests for virt-viewer windows port

[Fernando Lozano]

Hi Alon,
>> At least, the virt-viewer (remote-viewer) port should either embed a ssh
>> client or use an external putty under the covers (like Xming does), and
>> work with both ssh keys and password auth directly from the connection
>> dialog (which today is non-existant, just "type a URL")
> Sounds like a good idea to have an ssh tunnel to the guest. It's totally doable without extending the current protocol by using a new char-dev channel. Actually we may want to record the number of the channel in the protocol, but that's it. Other then that it requires changes all over, but small, and has been discussed before, just needs someone to love it enough ;)
I was thinking about a tunnel to the host, not to the guest, for guest 
console access, without having to configure and start ssh tunnels 
manually, outside virt-viewer/remote-viewer.

[that's right, if you want the guest console you connect to the host]

Having virt-viewer / remote-viewer setup a tunnel for the guest would be 
very usefull to get a bash prompt (not a console GUI) and transfer files 
using SFTP. But for now I want just guest console access.

>> And it should be able to get the spice TCP port from libvirtd, instead
>> of having the user find and provide the correct port on the host for the
>> desired guest. It should be smart enough to setup a ssh tunnel if needed
>> or ask for tls certificates if it can't find them.
> If your use case is libvirtd based, you can use virt-viewer directly,
The current windows port has only a barely usable remote-viewer. When I 
try to start virt-viewer, it complains missing libssp-0.dll.

And I can't make spice+tls work. :-( Using TLS requires extra setup on 
the server side, I guess the easier path for windows users would be 
having remote-viewer or virt-viewer handle ssh tunnels.

It looks like on Linux remote-viewer creates the ssh tunnel itself, but 
not on the windows port.


[]s, Fernando Lozano