Bug 913607

Summary: RFE: Support tunnelling SPICE over websockets
Product: Red Hat Enterprise Linux 6 Reporter: Daniel Berrange <berrange>
Component: spice-gtkAssignee: Marc-Andre Lureau <marcandre.lureau>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 6.4CC: acathrow, bderzhavets, berrange, cfergeau, dblechte, josh, marcandre.lureau, sputhenp, tvvcox
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-04 12:25:52 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 883504, 980853    

Description Daniel Berrange 2013-02-21 10:36:03 EST
Description of problem:
OpenStack recently gained support for exposing VM consoles using SPICE. The compute Nodes expose regular (plain TCP, not TLS) QEMU spice port to the internal mgmt network. There is then a proxy which tunnels SPICE over websockets, applying SSL if required, thus exposing the VMs to the internet. The OpenStack web mgmt console uses SPICE HTML5 to connect to the VMs.

Great as SPICE HTML5 is, it doesn't really offer any compelling benefits over the noVNC console. To take advantage of SPICE features like multi-monitor, USB passthrough, etc, etc we need to enable people to use a standalone SPICE client like remote-viewer.

To enable remote-viewer to connect to OpenStack, we ideally need spice-gtk to be able to support WebSockets tunnelling of SPICE. There are just two pieces of info required to connect - a hostname/port for the proxy (which never changes per VM), and a cookie (which provides authentication and identifies the specific VM host/port that the proxy forwards to).


Version-Release number of selected component (if applicable):
0.17
Comment 2 RHEL Product and Program Management 2013-02-25 01:47:54 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 3 Marc-Andre Lureau 2013-06-25 09:30:51 EDT
Daniel, can you give more details on how the info host/port and cookie will be given to the client? Can we assume it rely on .vv connection file parameters?

Should remote-viewer/spice-gtk support ws:// uri ? How would it differentiate between spice or vnc then? Apparently, there is a subprotocol field for that, and we should consider registering: http://www.iana.org/assignments/websocket/websocket.xml. That would need some negociation in this case.

Is this somehow testable today with openstack? Or can it just be implemented against a websockify spice server?

thanks
Comment 4 Daniel Berrange 2013-06-25 09:45:58 EDT
For the way OpenStack has implemented the proxy you need to connect to a URL

   http(s)://hostname:port/websockify

and have set a cookie called 'token' containing the authentication token openstack provided. The 'token' values are time limits, single use only auth keys.

Now what actual URI we define for use with spice-gtk / remote-viewer is rather up to us to define, since the OpenStack API doesn't define this. For a generic websocket proxied remote viewer, we could say something like this is required:

 spice+ws://hostname:port/websockify?token=foobar

For an OpenStack specific URI though,  we could use an spice+openstack://  URI scheme and pass in the hostname of the openstack authentication server (keystone) along with the UUID of the virtual instance. Then auto-lookup the hostname/port + token of the virtual instance display, as we do with oVirt.
Comment 5 Marc-Andre Lureau 2013-06-25 10:02:15 EDT
(In reply to Daniel Berrange from comment #4)
> For the way OpenStack has implemented the proxy you need to connect to a URL
> 
>    http(s)://hostname:port/websockify
> 
> and have set a cookie called 'token' containing the authentication token
> openstack provided. The 'token' values are time limits, single use only auth
> keys.

Ok, is this already implemented in openstack? It will redirect websocket connection from this address to the server? Is it documented somewhere?

> Now what actual URI we define for use with spice-gtk / remote-viewer is
> rather up to us to define, since the OpenStack API doesn't define this. For
> a generic websocket proxied remote viewer, we could say something like this
> is required:
> 
>  spice+ws://hostname:port/websockify?token=foobar
> 
> For an OpenStack specific URI though,  we could use an spice+openstack:// 
> URI scheme and pass in the hostname of the openstack authentication server
> (keystone) along with the UUID of the virtual instance. Then auto-lookup the
> hostname/port + token of the virtual instance display, as we do with oVirt.

I am not that familiar with openstack (keystone), or oVirt. So I don't get that part. I suppose "token" here is the same as the token in cookie in openstack example above, but the auth server will require login/pass.

I am afraid this bug can't be implemented simply with a websockify spice server, since it requires some cookie handling. So it would be nice to have some help how to setup openstack (or use an instance we can try against)
Comment 6 Daniel Berrange 2013-06-25 10:08:43 EDT
(In reply to Marc-Andre Lureau from comment #5)
> (In reply to Daniel Berrange from comment #4)
> > For the way OpenStack has implemented the proxy you need to connect to a URL
> > 
> >    http(s)://hostname:port/websockify
> > 
> > and have set a cookie called 'token' containing the authentication token
> > openstack provided. The 'token' values are time limits, single use only auth
> > keys.
> 
> Ok, is this already implemented in openstack? It will redirect websocket
> connection from this address to the server? Is it documented somewhere?

Yep, latest openstack includes this SPICE websock proxy support. It doesn't redirect the client, rather you're going via a tunnelled proxy. So the single public facing websockets display server, can be used to access VMs across any host in the cloud. Thus the individual virtualization hosts are not public facing.

> 
> > Now what actual URI we define for use with spice-gtk / remote-viewer is
> > rather up to us to define, since the OpenStack API doesn't define this. For
> > a generic websocket proxied remote viewer, we could say something like this
> > is required:
> > 
> >  spice+ws://hostname:port/websockify?token=foobar
> > 
> > For an OpenStack specific URI though,  we could use an spice+openstack:// 
> > URI scheme and pass in the hostname of the openstack authentication server
> > (keystone) along with the UUID of the virtual instance. Then auto-lookup the
> > hostname/port + token of the virtual instance display, as we do with oVirt.
> 
> I am not that familiar with openstack (keystone), or oVirt. So I don't get
> that part. I suppose "token" here is the same as the token in cookie in
> openstack example above, but the auth server will require login/pass.

Keystone is the name of OpenStack's authentication server. The user will typically have access to that server by setting env variables with their authentication credentials. With such authenticated access to keystone you can then access the compute service, where you can find out the address of the display server and ask for a one-time token to connect to a specify guest.

> I am afraid this bug can't be implemented simply with a websockify spice
> server, since it requires some cookie handling. So it would be nice to have
> some help how to setup openstack (or use an instance we can try against)

Ping me out of band and I can help you setup a suitable openstack instance, or failing that I can give you access to one of mine.
Comment 8 Marc-Andre Lureau 2013-07-28 13:52:12 EDT
I started a blueprint to use HTTP proxy instead. The patch are in gerrit (spice-http-proxy)

https://blueprints.launchpad.net/nova/+spec/spice-http-proxy
Comment 9 RHEL Product and Program Management 2013-10-14 00:14:35 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 10 josh 2013-10-30 23:37:24 EDT
It appears that the spice-http-proxy code has been abandoned. Has there been any further definition or documentation of the websockets approach? What's the proper way, for example to wrap the spice-gtk client? It wants a standard spice uri which ends up choking on the token when passed.
Comment 11 Marc-Andre Lureau 2013-10-31 08:11:52 EDT
(In reply to josh from comment #10)
> It appears that the spice-http-proxy code has been abandoned. Has there been
> any further definition or documentation of the websockets approach? What's
> the proper way, for example to wrap the spice-gtk client? It wants a
> standard spice uri which ends up choking on the token when passed.

It is not abandoned, in the sense that I still think it's a better approach than implementing websockets: https://blueprints.launchpad.net/nova/+spec/spice-http-proxy. all the patches were ready to be merged for a while.

I think implementing websocket in the native client is the wrong approach.
Comment 12 Marc-Andre Lureau 2014-02-18 13:59:20 EST
Daniel, do you still think this is a desirable solution or should we close this bug now? thanks
Comment 13 Daniel Berrange 2014-02-19 05:41:50 EST
If we do the plain https tunnelling of SPICE in openstack, then client support for the websockets tunnelling would not be a critical feature any more.
Comment 14 Marc-Andre Lureau 2014-06-04 12:14:17 EDT
Tbh, I still think this doesn't make sense for Spice & spice-gtk.
Comment 15 RHEL Product and Program Management 2014-06-04 12:25:52 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.