Re: [Engine-devel] SPICE IP override

On 11/15/2012 09:06 AM, Yaniv Kaul wrote: > ----- 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...). ok, so no engine, but just client side support for PAC?