On 11/07/2012 12:12 PM, Itamar Heim wrote:
On 11/07/2012 10:52 AM, Simon Grinberg wrote:
----- Original Message -----
From: "Itamar Heim" <ih...@redhat.com>
To: "Simon Grinberg" <si...@redhat.com>
Cc: engine-devel@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.skriva...@redhat.com>
To: engine-devel@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.
If they are using VPN, they don't need all that NAT stuff. If they are
using VPN and STILL need that NAT stuff, it is probably on the same box
(FW+NAT+VPN), and then it's a non-issue. If the VPN and the NAT is NOT
on the same setup, best of luck to them.
Y.
+ 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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
