[Engine-devel] SPICE IP override

[Yaniv Kaul]

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