Re: [Engine-devel] SPICE IP override

----- Original Message ----- > 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...? Doesn't this presume that the user allows a single site to set his proxy settings, which seems rather insecure?

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