Re: [Qemu-devel] Re: Spice project is now open

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Dec 14, 2009 at 08:42:12AM -0600, Anthony Liguori wrote:
> Avi Kivity wrote:
> >On 12/13/2009 01:46 AM, Anthony Liguori wrote:
> >>
> >>Dan Berrange and I have been talking about being able to move VNC 
> >>server into a central process such that all of the VMs can have a 
> >>single VNC port that can be connected to.  This greatly simplifies 
> >>the firewalling logic that an administrator has to deal with.   
> >>That's a problem I've already had to deal with for our management 
> >>tools.  We use a private network for management and we bridge the VNC 
> >>traffic into the customers network so they can see the VGA session.  
> >>But since that traffic can be a large range of ports and we have to 
> >>tunnel the traffic through a central server to get into the customer 
> >>network, it's very difficult to setup without opening up a mess of 
> >>ports.  I think we're currently opening a few thousand just for VNC.
> >
> >Seems to me the best way to handle this is to run an accept() in a 
> >server and hand the resulting fd to the vnc server in qemu using ... 
> >wait for it ... SCM_RIGHTS.
> >
> >I'm just happy every time someone lobs a question into the air that 
> >can be answered using SCM_RIGHTS.
> 
> That's actually a great idea made even better by the use of SCM_RIGHTS :-)
> 
> I think it's a bit trickier though because ideally you would want to use 
> the vnc protocol to negotiate which vm you're connecting to.  That 
> implies that you actually need to hand over the fd in a setup state.  
> It's complicated by any encryption protocol too.

The model I had in mind was for the proxy to define a VNC extension that
allows the client to query what 'desktops' are available and request
switching between them at any time. The list of desktop would of course
be authorized per client, and strong authentication is a must for this.

Any time a switch was made, the RFB protocol would return to the 
'ServerInit' state. The idea is that you should not assume a homogenous 
environment, and you really don't want to fall down to the lowest common
denominator of extensions, nor have the proxy doing re-encoding on the FB
data updates. Returning to the ServerInit state allowing the client to
re-negotiate the set of encodings for the new desktop, and so the proxy 
can be fairly stateless and while needing to understand the wire protocol,
it can just pass through the actual FB update data unchanged.

The combo of the an extension for switching desktops on the fly and the
encryption state problem doesn't really seem to fit with passing the VNC
FD over with SCM_RIGHTS.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|