[Engine-devel] SPICE IP override

[Simon Grinberg]

----- Original Message ----- 

> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>, "Michal Skrivanek"
> <michal.skrivanek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, November 11, 2012 11:45:34 AM
> Subject: Re: [Engine-devel] SPICE IP override

> On 11/07/2012 10:52 AM, 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?
> 
> Lets not re-invent the wheel. This problem has been pondered before
> and solved[1], for all scenarios:
> internal clients connecting to internal resources;
> internal clients connecting to external resources, without the need
> for any intermediate assistance
> external clients connecting to internal resources, with the need for
> intermediate assistance.
> VPN clients connecting to internal resources, with or without an
> internal IP.

> Any other solution you'll try to come up with will bring you back to
> this standard, well known (along with its faults) method.

> The browser client will use PAC to determine how to connect to the
> hosts and will deliver this to the client. It's also a good path
> towards real proxy support for Spice.
> (Regardless, we still need to deal with the Spice protocol's
> migration command of course).

> [1] http://en.wikipedia.org/wiki/Proxy_auto-confi

If I'm reading this correctly the engine should prepare a URL with a PAC script for the Spice client, where the spice client should connect basea on the info in the PAC file. It's still means that we need to provide both internal and external connection option (just through PAC file). 

Nice. 





> > Simon.
> 
> > > Thanks,
> > 
> 
> > > michal
> > 
> 

> > > _______________________________________________
> > 
> 
> > > Engine-devel mailing list Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> > _______________________________________________
> 
> > Engine-devel mailing list Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel