Use native remote client when available

[AceBlade258]

I would like to use the spice native client (virt-viewer) when connecting to guests through the kimchi console. The performance (in both local resource usage, and user experience) is dramatically improved with the use of the native client.

I don't see any reason to limit this to the spice protocol, however, because the virt-viewer application also supports VNC.

[danielhb]

Doing the .vv file to launch the virt-viewer is simple. A file with this content can do the job. Save it as "launcher.vv" and if you have virt-viewer installed Gnome will automatically recognize this file as "Open with Remote Desktop ..." in double click.

[virt-viewer]
type=vnc
host=localhost
port=5905
delete-this-file=1

Now, we can't just point this file to the websocket Kimchi opens and hope it works. VNC uses RFB protocol, which runs in plain TCP. Websocket is not a plain TCP socket - it has its own connection scheme, framing and security scheme. It uses HTTP messages in its handshaking process, for starters (see more here http://tools.ietf.org/html/rfc6455 ).

One alternative would be to create the vv file pointing to the opened VNC port as is, 5905 for example, and then let the user handle any firewall issues. Kimchi can even make an effort and open up the ports automatically. I am mention this just be on the record - both are not viable in my opinion.

noVNC uses websockify, a websocket/TCP proxy to allow communication of its client written in HTML5 and the server talking TCP. I don't know if it's viable/worth the effort using this kind of proxy to do what we want (would have to proxy the connection between the desktop VNC client and Kimchi too), but I'll investigate.

@alinefm @laggarcia thoughts?

[laggarcia]

On 06/04/2016 09:14 AM, Daniel Henrique Barboza wrote: <...>

One alternative would be to create the vv file pointing to the opened VNC port as is, 5905 for example, and then let the user handle any firewall issues. Kimchi can even make an effort and open up the ports automatically. I am mention this just be on the record - both are not viable in my opinion.

I agree none of these options are user friendly.

noVNC uses websockify, a websocket/TCP proxy to allow communication of its client written in HTML5 and the server talking TCP. I don't know if it's viable/worth the effort using this kind of proxy to do what we want (would have to proxy the connection between the desktop VNC client and Kimchi too), but I'll investigate.

What would be your suggestion here? Kimchi would create a fake page running on its default HTTP server port and virt-viewer would connect to that fake page? Then that fake page would just use websockify in order to talk to the websocket Kimchi opens, which would redirect to the localhost VNC port? Even though I think this can work, I think it is overly complex.

@alinefm https://github.com/alinefm @laggarcia https://github.com/laggarcia thoughts?

Does virt-viewer support reverse VNC connections? Not sure if this is possible in SPICE, though.

Virt-viewer .vv files were created specifically for oVirt engine (this is quite explicit in the virt-viewer source code). We may want to see what oVirt engine is doing in this case.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kimchi-project/kimchi/issues/944#issuecomment-223752447, or mute the thread https://github.com/notifications/unsubscribe/AEirb46fwM-vlA59CxC4vS67-T4zKqblks5qIWwngaJpZM4IccBn.

[laggarcia]

According to oVirt documentation, ports 5900-6923 must be opened on the hypervisor ("Remote guest console access via VNC and SPICE. These ports must be open to facilitate client access to virtual machines." --- source; http://www.ovirt.org/documentation/admin-guide/administration-guide/#Virtualization_Host_Firewall_Requirements1).

How difficult would it be for Kimchi to manage firewall rules? Or should we just ask users to open all these ports as well (I'd rather prefer not)?

[danielhb]

On 06/05/2016 12:00 AM, Leonardo Garcia wrote:

According to oVirt documentation, ports 5900-6923 must be opened on the hypervisor ("Remote guest console access via VNC and SPICE. These ports must be open to facilitate client access to virtual machines." --- source; http://www.ovirt.org/documentation/admin-guide/administration-guide/#Virtualization_Host_Firewall_Requirements1).

Oh dear ...

How difficult would it be for Kimchi to manage firewall rules? Or should we just ask users to open all these ports as well (I'd rather prefer not)?

Easiest solution would be to document that this feature, using virt-viewer to access VMs, requires ports 5900-6923 to be opened up manually by the user.

We can make Kimchi handle firewall rules, enabling rules for this specific port range when Kimchi starts and disabling it when Kimchi exits. Does it solve the problem? Not completely. There's no restriction about which port to use for the VNC of the VM. If I create a VM and I want it to use port 10000 for its VNC server, this rule will not cover it.

One workaround for it would be to throw a warning when the user downloads a .vv file for a VM which uses a port outside of this 5900-6923 range like "VNC/SPICE server of the VM uses port N, please check firewall rules for that port".

An alternative is to open ports on demand. We check the VNC/Spice port the VMs uses and, if the user chooses to use virt-viewer, we open only that specific port. We can close the firewall port when the VM is shut down or WoK is shut down. We would need to actually check if the port is already opened and, in that case, we don't need to open it and close it on VM/WoK shutdown. This would be more elegant than leaving a whole array of ports opened, but it will require more effort to implement it.

I am not fond of any of these implementation options because they all require user intervention and/or firewall management at Kimchi. So I am all ears about them.

And I just realized that GInger does not have a firewall management feature. If Ginger had it, then I would feel more confortable/less miserable asking the user to open up ports for this Kimchi feature.

Daniel

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/kimchi-project/kimchi/issues/944#issuecomment-223790326, or mute the thread https://github.com/notifications/unsubscribe/AA053GTnjqibPCoB261U3SzqJPkh4c6uks5qIjvhgaJpZM4IccBn.

[danielhb]

I have good news about this feature. There's a virt-viewer option called "proxy" which receives a proxy URL to tunnel the connection. Kimchi already has such URL in place due to noVNC/spice-html5 connections. NGinx places it as http://:8000/websockify

This is how I've tested it: I've used another computer, an Ubuntu 16.04 LTS, to connect into my laptop running Kimchi. I've used the following .vv file:

[virt-viewer] 
type=vnc
host=my_laptop_ip
port=vnc_port
proxy=http://my_laptop_ip:8000/websockify

And it worked:

I need to verify if it works with Spice as well. Assuming it does, all that remains is to create this file and make it available for download. Of all the infos required to create it, the only one I am not sure how to fetch is the proxy URL, which is a nginx configuration that I am not sure if it's registered somewhere in WoK.

Daniel

[danielhb]

Confirmed to work with Spice by just changing the line type=vnc to type=spice

[danielhb]

The backend of this feature is already available upstream. I think it's time for the UI guys to take a look into it.

Basically what we need here is simply a link right below "View Console" with a name like "View in Virt Viewer" that will download the script and, if the browser is properly configured, will provide the "Open As .." option to launch Virt Viewer with the VNC/Spice session.

I'll set milestone as "Backlog" for now and will clear assignee. @samhenri and/or @peterpennings can take this assignment later on.

[alinefm]

Patches applied upstream: from abb511449c12c151e01f643dbb0dcfad6b700928 to 24cc635d8d0180bc77a6473a511dc14fed6d3fdb

[alinefm]

Ops... UI is still missing. I will keep it open to track that.

[q2dg]

Any news on this? Thanks!