----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Simon Grinberg" <simon@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.skrivanek@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