[Engine-devel] SPICE IP override

Thu Nov 15 08:42:19 UTC 2012

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.
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
>>