[Engine-devel] SPICE IP override

[Itamar Heim]

On 11/07/2012 10:52 AM, Simon Grinberg wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, November 7, 2012 10:46:24 AM
>> Subject: Re: [Engine-devel] SPICE IP override
>>
>> On 11/07/2012 09: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?
>>
>> i think this is over complicating things.
>> I'd expect someone that wants to handle internal and external
>> differently to use DNS, and resolve the DNS differently for external
>> and
>> internal clients.
>
> That will not necessarily solve the issue - what about WAN users from home? the DNS is not under their control -> they need redirection to the public facing NAT servers.

if a public service, not relevant.
if a private service, i expect they would be using a VPN, with dns 
resolution provided by the organization for external vpn users, if they 
need to resolve IPs differently internally and externally.

>
> + At least currently (and this must change, unless you accept the proposal I've raised) the engine sends fqdn if the display network in on the engine management network and IP on any other selected Display-Network.

not with this patch, which sends the dns the admin configured, 
regardless of display logical network used.

>
> No DNS will help you in this case, so you still need alternate FQDN.
>
>>
>> (note this is different from specifying the spice proxy address at
>> cluster level, which is something you want user to choose if they
>> want
>> to enable or not per their location)
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>