Re: [Engine-devel] SPICE IP override

On 11/15/2012 08:33 AM, Yaniv Kaul wrote: > On 11/15/2012 06:10 AM, Itamar Heim wrote: >> 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"<michal.skrivanek(a)redhat.com> >>>>> 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...? > > I would actually encourage the customers to use their own corporate > PAC > and add the information to it. so you are suggesting that there is no need at all to deal with proxy definition/configuration at ovirt engine/user portal level?