Re: [Engine-devel] SPICE IP override

On 11/07/2012 10:52 AM, Simon Grinberg wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" <iheim(a)redhat.com&gt; >> To: "Simon Grinberg" <simon(a)redhat.com&gt; >> Cc: engine-devel(a)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(a)redhat.com&gt; >>>> To: engine-devel(a)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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel