Re: [Engine-devel] SPICE IP override

----- Original Message ----- > 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? I expect the admin/user portal to send the result of the PAC processing to the Spice client. I don't think the Spice client should execute the PAC (it's a Javascript...).