12:16 p.m.
On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Tuesday, November 6, 2012 10:39:58 PM
> Subject: [Engine-devel] SPICE IP override
>
> Hi all,
> On behalf of Tomas - please check out the proposal for enhancing our
> SPICE integration to allow to return a custom IP/FQDN instead of the
> host IP address.
> http://wiki.ovirt.org/wiki/Features/Display_Address_Override
> All comments are welcome...
My 2 cents,
This works under the assumption that all the users are either outside
of the organization or inside.
But think of some of the following scenarios based on a topology where
users in the main office are inside the corporate network while users
on remote offices / WAN are on a detached different network on the
other side of the NAT / public firewall :
With current 'per host override' proposal:
1. Admin from the main office won't be able to access the VM console
2. No Mixed environment, meaning that you have to have designated
clusters for remote offices users vs main office users - otherwise
connectivity to the console is determined based on scheduler
decision, or may break by live migration.
3. Based on #2, If I'm a user travelling between offices I'll have to
ask the admin to turn off my VM and move it to internal cluster
before I can reconnect
My suggestion is to covert this to 'alternative' IP/FQDN sending the
spice client both internal fqdn/ip and the alternative. The spice
client should detect which is available of the two and auto-connect.
This requires enhancement of the spice client, but still solves all
the issues raised above (actually it solves about 90% of the use cases
I've heard about in the past).
Another alternative is for the engine to 'guess' or 'elect' which to
use, alternative or main, based on the IP of the client - meaning
admin provides the client ranges for providing internal host address
vs alternative - but this is more complicated compared for the
previous suggestion
Thoughts?
I agree with where you're going with this. The story I'd like to see
supported is close to this. We have external customers who should know
nothing about our internal network, but should be able to access the
console of their VMs. Currently we do this with a custom frontend which
uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy,
but we'd like to move to the standard UI. Currently the console
connection prevents us from doing so.
Users are able to create VMs based on the resources they have (RAM, CPU,
storage, network) without admin intervention. This means we'd like to
see this override on a cluster / DC / global level so there is no need
for admin intervention. Ideally this would also come with a programmable
proxy so the engine can enable/disable forwards instead of a NAT
firewall.