[Engine-devel] SPICE IP override

Thu Nov 15 08:52:51 UTC 2012

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

I'm referring to the current feature page as is (taking out the rest of the discussion): 
It lacks solution for migration:
1. You have host A, and B, both with overridden IP set
2. On initial connect the browser provides the connection details using host A 'override IP' settings
3. VM Migrates from A to B
4. Now it's Qemu providing the destination connection details - it will provide the internal IP of host B

Connection breaks !!!

Again, unless I'm missing something and live migration destination is provided by the web client/engine to the spice client (somehow)

> 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 at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 