Re: [Engine-devel] SPICE IP override

From: "Yaniv Kaul" <ykaul(a)redhat.com&gt; To: "Itamar Heim" <iheim(a)redhat.com&gt; Cc: "Simon Grinberg" <simon(a)redhat.com&gt;, engine-devel(a)ovirt.org Sent: Thursday, November 15, 2012 10:07:02 AM Subject: Re: [Engine-devel] SPICE IP override On 11/15/2012 09:35 AM, Itamar Heim wrote: > 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&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...? >>>> >>>> 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? Exactly. And of course, Spice protocol changes, without which all this effort is nice, but incomplete. Y. _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel