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

[Anthony Liguori <anthony@codemonkey.ws>]

Daniel P. Berrange wrote:
> 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.

I was thinking about it a bit differently.  I was envisioning the switch 
to be a one time thing as opposed to being able to switch back and forth.

A management app can see multiple guests by connecting repeatedly to the 
same port.  They can implement switching in the client which allows for 
clever things like caching state of multiple clients while not sending 
updates for clients that aren't actively displayed.

Regards,

Anthony Liguori