11:45 a.m.
This is a multi-part message in MIME format.
--------------030300080707090501020601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 11/07/2012 10:52 AM, Simon Grinberg wrote:
----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
> 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?
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
Simon.
> Thanks,
> michal
>
> _______________________________________________
> 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
--------------030300080707090501020601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/07/2012 10:52 AM, Simon Grinberg
wrote:<br>
</div>
<blockquote
cite="mid:1197121097.6204891.1352278334446.JavaMail.root@redhat.com"
type="cite">
<pre wrap="">
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Michal Skrivanek" <a
class="moz-txt-link-rfc2396E"
href="mailto:michal.skrivanek@redhat.com"><michal.skrivanek@redhat.com></a>
To: <a class="moz-txt-link-abbreviated"
href="mailto:engine-devel@ovirt.org">engine-devel@ovirt.org</a>
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.
<a class="moz-txt-link-freetext"
href="http://wiki.ovirt.org/wiki/Features/Display_Address_Override&q...
All comments are welcome...
</pre>
</blockquote>
<pre wrap="">
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?</pre>
</blockquote>
<br>
Lets not re-invent the wheel. This problem has been pondered before
and solved[1], for all scenarios: <br>
internal clients connecting to internal resources;<br>
internal clients connecting to external resources, without the need
for any intermediate assistance<br>
external clients connecting to internal resources, with the need for
intermediate assistance.<br>
VPN clients connecting to internal resources, with or without an
internal IP.<br>
<br>
Any other solution you'll try to come up with will bring you back to
this standard, well known (along with its faults) method.<br>
<br>
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.<br>
(Regardless, we still need to deal with the Spice protocol's
migration command of course).<br>
<br>
<br>
[1]
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://en.wikipedia.org/wiki/Proxy_auto-config">http:/...
<br>
<br>
<br>
<br>
<blockquote
cite="mid:1197121097.6204891.1352278334446.JavaMail.root@redhat.com"
type="cite">
<pre wrap="">
Simon.
</pre>
<blockquote type="cite">
<pre wrap="">
Thanks,
michal
_______________________________________________
Engine-devel mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/engine-devel">...
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Engine-devel mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/engine-devel">...
</pre>
</blockquote>
<br>
</body>
</html>
--------------030300080707090501020601--