----- Original Message ----- > From: "Yaniv Kaul" <yk...@redhat.com> > To: "Itamar Heim" <ih...@redhat.com> > Cc: "Simon Grinberg" <si...@redhat.com>, engine-devel@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"<michal.skriva...@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...).
And live migration? 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. 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 > > > > 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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel