Re: [Engine-devel] SPICE IP override

From: "Yaniv Kaul" <ykaul(a)redhat.com&gt; To: "Simon Grinberg" <simon(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, "Itamar Heim" <iheim(a)redhat.com&gt; Sent: Thursday, November 15, 2012 10:42:19 AM Subject: Re: [Engine-devel] SPICE IP override On 11/15/2012 10:33 AM, Simon Grinberg wrote: > > ----- Original Message ----- >> 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...). > And live migration? Read my email: "And of course, Spice protocol changes" > I don't completely understand how you can avoid executing the PAC > file if the destination host is provided by Qemu > (client_migrate_info) unless I'm confusing with something else and > it is the web client that delivers this info on migration. I'm not against executing the PAC. It just requires a javascript engine, which is a bit of an overkill for Spice client to start working with, no? I'm aware there is a critical gap with the Spice protocol, but all I'm saying is that any other idea you'll come up with to get the topology right is going to be a rewrite of the PAC idea. You will need to define the topology, and you'll need to lookup your current location against it. This is what PAC does. A Spice proxy would probably be able to solve the Spice protocol issue, as we expect the proxy to handle the host hand-over when migration happens, I reckon. > > P.S., > If it is Qemu, then I don't see the current feature page accounting > for that - IE, the hosts should also be informed on this override > IP Why? A host is rarely aware it is behind NAT. If it's because of the protocol issue, the protocol has to be changed.

Y. > > > >>> 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 >>