On 11/15/2012 06:13 AM, Andrew Cathrow wrote:
----- Original Message -----
From: "Itamar Heim" <ih...@redhat.com>
To: "Yaniv Kaul" <yk...@redhat.com>
Cc: "Simon Grinberg" <si...@redhat.com>, engine-devel@ovirt.org
Sent: Wednesday, November 14, 2012 11:10:21 PM
Subject: Re: [Engine-devel] SPICE IP override
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.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?
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...?
Doesn't this presume that the user allows a single site to set his proxy
settings, which seems rather insecure?
The PAC is retrieved via HTTPS, so it's supposedly secure.
In a corporate environment you have your company's PAC anyway.
Y.
_______________________________________________
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
