----- Original Message ----- > From: "Itamar Heim" <[email protected]> > To: "Yaniv Kaul" <[email protected]> > Cc: "Simon Grinberg" <[email protected]>, [email protected] > Sent: Wednesday, November 14, 2012 11:10:21 PM > Subject: Re: [Engine-devel] SPICE IP override > > On 11/11/2012 11:45 AM, Yaniv Kaul wrote: > > On 11/07/2012 10:52 AM, Simon Grinberg wrote: > >> > >> ----- Original Message ----- > >>> From: "Michal Skrivanek"<[email protected]> > >>> To:[email protected] > >>> 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-config > > so instead of a spice proxy fqdn field, we should just allow user to > specify a pac file which resides under something like > /etc/ovirt/engine/pac...?
Doesn't this presume that the user allows a single site to set his proxy settings, which seems rather insecure? > _______________________________________________ > Engine-devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
