Re: [Engine-devel] SPICE IP override

From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Yaniv Kaul" <ykaul(a)redhat.com&gt; Cc: "Simon Grinberg" <simon(a)redhat.com&gt;, engine-devel(a)ovirt.org 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&quot;&lt;michal.skrivanek(a)redhat.com&gt; >>> To:engine-devel@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-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...?

_______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel