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

[Gildas Le Nadan <gildas.ml@gmail.com>]

>> 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.
> 
> Actually my plan was to have a VNC proxy server, that sat between the
>  end user & the real VNC in QEMU. Specifically I wanted to allow for
> a model where the VNC server end users connected to for console
> servers was on a physically separate host from the VMs. I had a
> handful of use cases, mostly to deal with an oVirt deployment where
> console users could be from the internet, rather than an intranet.
> 
> - Avoiding the need to open up many ports on firewalls - Allow on the
> fly switching between any VMs the currently authenticated user was
> authorized to view without opening more connections (avoids needing
> to re-authenticate for each VM) - Avoid needing to expose
> virtualization hosts to console users, since console users may be
> coming in from an untrusted network, or even the internet itself. -
> Allow seemless migration where proxy server simply re-connects to the
> VM on new host, without the end user VNC connection ever noticing.

Hi,

Having a single well known port to connect to the VMs on an host would
be *awesome* as having one port per VM is sooo 1980's in terms of
manageability/secureability.

Actually both use cases described above are needed IMO:

- it would be great to have some sort of server running locally on the 
VM host so that you only have one open port on the VM host itself [1].

- it would be very usefull to have some sort of proxy mechanism that 
would allow redirection from a single host acting as a gateway between 
networks (be it internal or external networks).

The two of them could interact nicely with one connecting to the other 
if needed:

_______VM_Host________    _proxy_Host_     _client_machine_
|    1               | 2  |          |  3  |              |
|VM <-> local server |<-> |   proxy  | <-> |  client      |
|____________________|    |__________|     |______________|

I think one of the most important thing is that the proxy and the local 
server must behave exactly the same way and provide the same features 
(that is the protocol used on connection 2 should be the same as the one 
for connection 3).

This allow the client to work the same independently of the 
configuration/topology. The proxy allows for enterprise class features 
whereas the local server is enough for a small virtual infrastructure or 
even a single machine setup, but that should be transparent to the clients.

I guess there must exist a way to route the connection to the correct 
VM, so there should be something similar to the HTTP Host request-header 
to identify the VM the client wants to connect to [2].

Of course SASL support is mandatory but I guess Dan planned it anyway :)

Ideally there would be some sort of negociation mechanism so the client 
can ask what protocol (vnc, spice, ...) they want to use (if possible 
dynamically within a session if a user change its location/if its need 
evolve).

Obviously both shouldn't need to be run as root.

I guess the proxy should be a project on his own and not part of qemu 
since it is more of an enterprise feature while the local server could 
be added to qemu? Of course since there are some common features, it 
would probably make sense to share some code.

Concerning the proxy, there are all sorts of goodies I would expect from 
it (on top of seamless migration and on-the-fly switching) :
- flexibility in the choice of the authorization backend
- since it is a SPOF, it would be nice for it to work as a cluster (in 
active/passive with failover or better as an active/active cluster)

Since this proxy can be used as a connection broker to either physical 
or virtual machines, load-balancing and session management features 
would be nice.

Of course in a perfect world this wouldn't be a single company project ;)

My humble 2 cents as an operations person,
Gildas

-- 
[1] firewalling is also important on internal networks if you work in a 
large environment, and having a single port makes it easier to 
understand what is going on when diagnosing issues.

[2] You also need to point to the correct host. How you want to 
"publish" the VM/VM Host association so the proxy can route is an 
interesting problem on its own, especially since VM can (and will) 
migrate. There are probably many ways to do this including DNS SRV, 
LDAP, local DB, and having flexibility for this in the proxy is a bonus.