[Engine-devel] SPICE IP override

[Simon Grinberg]

----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Simon Grinberg" <simon at redhat.com>, engine-devel at 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 at redhat.com>
> >>>>>>>> To:engine-devel at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>