----- 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"<[email protected]> > >>>>> To:[email protected] > >>>>> 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...). Y. > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
