[Engine-devel] SPICE IP override

[David Jaša]

Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 11:16 +0100:
> On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
> > ----- Original Message -----
> > > From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> > > To: engine-devel at 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.

You could do that with this proposal, if you:
1) DNAT some external-facing IPs to your hypervisor display network IPs
2) resolve display network FQDN to the DNATing machine IPs for external
queries.

David

> 
> 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.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24