qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gildas Le Nadan
Subject: Re: [Qemu-devel] Re: Spice project is now open
Date: Sun, 13 Dec 2009 15:56:24 +0100
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]