[Engine-devel] SPICE IP override

[Yaniv Kaul]

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