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.