[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... Thanks, michal
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@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? Simon.
Thanks, michal
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/07/2012 09:52 AM, Simon Grinberg wrote:
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@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. (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)
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Simon Grinberg" <simon@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.skrivanek@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. + 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. 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
On 11/07/2012 10:52 AM, Simon Grinberg wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Simon Grinberg" <simon@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.skrivanek@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.
+ 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
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" <iheim@redhat.com> To: "Simon Grinberg" <simon@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.skrivanek@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
On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@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 agree with where you're going with this. The story I'd like to see supported is close to this. We have external customers who should know nothing about our internal network, but should be able to access the console of their VMs. Currently we do this with a custom frontend which uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy, but we'd like to move to the standard UI. Currently the console connection prevents us from doing so. Users are able to create VMs based on the resources they have (RAM, CPU, storage, network) without admin intervention. This means we'd like to see this override on a cluster / DC / global level so there is no need for admin intervention. Ideally this would also come with a programmable proxy so the engine can enable/disable forwards instead of a NAT firewall.
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 11:16 +0100:
On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@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 agree with where you're going with this. The story I'd like to see supported is close to this. We have external customers who should know nothing about our internal network, but should be able to access the console of their VMs. Currently we do this with a custom frontend which uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy, but we'd like to move to the standard UI. Currently the console connection prevents us from doing so.
You could do that with this proposal, if you: 1) DNAT some external-facing IPs to your hypervisor display network IPs 2) resolve display network FQDN to the DNATing machine IPs for external queries. David
Users are able to create VMs based on the resources they have (RAM, CPU, storage, network) without admin intervention. This means we'd like to see this override on a cluster / DC / global level so there is no need for admin intervention. Ideally this would also come with a programmable proxy so the engine can enable/disable forwards instead of a NAT firewall. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Jaša wrote:
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 11:16 +0100:
On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@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 agree with where you're going with this. The story I'd like to see supported is close to this. We have external customers who should know nothing about our internal network, but should be able to access the console of their VMs. Currently we do this with a custom frontend which uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy, but we'd like to move to the standard UI. Currently the console connection prevents us from doing so.
You could do that with this proposal, if you: 1) DNAT some external-facing IPs to your hypervisor display network IPs 2) resolve display network FQDN to the DNATing machine IPs for external queries.
I imagine you need 1 external-facing IP per host, which makes it expensive to scale since IPv4 space is very limited. This is why I suggested a proxy. In theory this could also be used to modify a forward to have seamless host migrations because the end point for the client wouldn't change.
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 12:08 +0100:
On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Jaša wrote:
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 11:16 +0100:
On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@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 agree with where you're going with this. The story I'd like to see supported is close to this. We have external customers who should know nothing about our internal network, but should be able to access the console of their VMs. Currently we do this with a custom frontend which uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy, but we'd like to move to the standard UI. Currently the console connection prevents us from doing so.
You could do that with this proposal, if you: 1) DNAT some external-facing IPs to your hypervisor display network IPs 2) resolve display network FQDN to the DNATing machine IPs for external queries.
I imagine you need 1 external-facing IP per host, which makes it expensive to scale since IPv4 space is very limited.
That's the cost of quick-to-implement solution. If it is possible to have per-host display port range, you could work this limitation around by setting non-overlapping ranges for each host and use a single proxy or DNAT machine that would decide which port to forward based on the range. David
This is why I suggested a proxy. In theory this could also be used to modify a forward to have seamless host migrations because the end point for the client wouldn't change. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
On Wed, Nov 07, 2012 at 12:40:50PM +0100, David Jaša wrote:
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 12:08 +0100:
On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Jaša wrote:
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 11:16 +0100:
On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@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 agree with where you're going with this. The story I'd like to see supported is close to this. We have external customers who should know nothing about our internal network, but should be able to access the console of their VMs. Currently we do this with a custom frontend which uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy, but we'd like to move to the standard UI. Currently the console connection prevents us from doing so.
You could do that with this proposal, if you: 1) DNAT some external-facing IPs to your hypervisor display network IPs 2) resolve display network FQDN to the DNATing machine IPs for external queries.
I imagine you need 1 external-facing IP per host, which makes it expensive to scale since IPv4 space is very limited.
That's the cost of quick-to-implement solution.
If it is possible to have per-host display port range, you could work this limitation around by setting non-overlapping ranges for each host and use a single proxy or DNAT machine that would decide which port to forward based on the range.
I was also thinking about port ranges, but I have no idea how hard it is to implement. It does sound like a good balance between quick-to-implement and usability in production.
On Wed, 2012-11-07 at 12:40 +0100, David Jaša wrote:
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 12:08 +0100:
On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Jaša wrote:
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 11:16 +0100:
On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@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 agree with where you're going with this. The story I'd like to see supported is close to this. We have external customers who should know nothing about our internal network, but should be able to access the console of their VMs. Currently we do this with a custom frontend which uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy, but we'd like to move to the standard UI. Currently the console connection prevents us from doing so.
You could do that with this proposal, if you: 1) DNAT some external-facing IPs to your hypervisor display network IPs 2) resolve display network FQDN to the DNATing machine IPs for external queries.
I imagine you need 1 external-facing IP per host, which makes it expensive to scale since IPv4 space is very limited.
That's the cost of quick-to-implement solution.
If it is possible to have per-host display port range, you could work this limitation around by setting non-overlapping ranges for each host and use a single proxy or DNAT machine that would decide which port to forward based on the range.
I am a colleague of Ewoud, and want to explain a bit more about how we currently have implemented this. All our virtualization hosts, but also the manager only live in the internal network. We have written a webapplication that is a self-service portal for our customers. This webapplication lives on a host that is publicly reachable. This host can also reach the virtualization servers on the internal network. Now for all actions except for viewing a console the webhost only needs to access the api, so what happens when a user wants to view the console (we currently use vnc): On the webhost we have reserved a number of ports. Api request is made to get the host/port, and we set the ticket (vnc password). We create a tunnel (currently use socat, but can of course also be DNAT or any kind of proxy) that connects one of the free ports on the external webhost to the host/port combo we got back from the api. This is a very simple implementation, but it works well in our experience. For added points you can make the proxy smarter, things like handling vm migrations and maybe adding websockets support for a html5 spice client ;) Kind regards, Sander
Sander Hoentjen píše v Pá 09. 11. 2012 v 17:07 +0100:
On Wed, 2012-11-07 at 12:40 +0100, David Jaša wrote:
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 12:08 +0100:
On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Jaša wrote:
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 11:16 +0100:
On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
----- Original Message ----- > From: "Michal Skrivanek" <michal.skrivanek@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 agree with where you're going with this. The story I'd like to see supported is close to this. We have external customers who should know nothing about our internal network, but should be able to access the console of their VMs. Currently we do this with a custom frontend which uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy, but we'd like to move to the standard UI. Currently the console connection prevents us from doing so.
You could do that with this proposal, if you: 1) DNAT some external-facing IPs to your hypervisor display network IPs 2) resolve display network FQDN to the DNATing machine IPs for external queries.
I imagine you need 1 external-facing IP per host, which makes it expensive to scale since IPv4 space is very limited.
That's the cost of quick-to-implement solution.
If it is possible to have per-host display port range, you could work this limitation around by setting non-overlapping ranges for each host and use a single proxy or DNAT machine that would decide which port to forward based on the range.
I am a colleague of Ewoud, and want to explain a bit more about how we currently have implemented this. All our virtualization hosts, but also the manager only live in the internal network. We have written a webapplication that is a self-service portal for our customers. This webapplication lives on a host that is publicly reachable. This host can also reach the virtualization servers on the internal network. Now for all actions except for viewing a console the webhost only needs to access the api, so what happens when a user wants to view the console (we currently use vnc): On the webhost we have reserved a number of ports. Api request is made to get the host/port, and we set the ticket (vnc password). We create a tunnel (currently use socat, but can of course also be DNAT or any kind of proxy) that connects one of the free ports on the external webhost to the host/port combo we got back from the api. This is a very simple implementation, but it works well in our experience.
This would work with spice as well apart from one thing -- migration. To support it really cleanly in these cases, one of these two things would have to exist: * spice proxy that would handle migrations on client behalf (but then you'd lose end-to-end encryption) * tweak to libvirt and vdsm and engine (engine via upcoming engine plugins maybe?) so that when migration with connected client is about to begin, vdsm will ask engine for external ip/fqdn:port that will match the ports it is about to configure for qemu and instruct libvirt to send these values to client_migrate_info qemu command instead of direct host/port/tls-port values. 2nd way seems more appropriate to me but the "ask engine to ask for external ip and ports" sounds like something that won't be easy to get properly. David
For added points you can make the proxy smarter, things like handling vm migrations and maybe adding websockets support for a html5 spice client ;)
Kind regards, Sander
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
----- Original Message -----
From: "Sander Hoentjen" <sander@hoentjen.eu> To: engine-devel@ovirt.org Sent: Friday, November 9, 2012 11:07:39 AM Subject: Re: [Engine-devel] SPICE IP override
On Wed, 2012-11-07 at 12:40 +0100, David Jaša wrote:
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 12:08 +0100:
On Wed, Nov 07, 2012 at 11:23:27AM +0100, David Jaša wrote:
Ewoud Kohl van Wijngaarden píše v St 07. 11. 2012 v 11:16 +0100:
On Wed, Nov 07, 2012 at 03:52:14AM -0500, Simon Grinberg wrote:
----- Original Message ----- > From: "Michal Skrivanek" <michal.skrivanek@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 agree with where you're going with this. The story I'd like to see supported is close to this. We have external customers who should know nothing about our internal network, but should be able to access the console of their VMs. Currently we do this with a custom frontend which uses the API (and is about as old as the RHEV 2.2 API) and a TCP proxy, but we'd like to move to the standard UI. Currently the console connection prevents us from doing so.
You could do that with this proposal, if you: 1) DNAT some external-facing IPs to your hypervisor display network IPs 2) resolve display network FQDN to the DNATing machine IPs for external queries.
I imagine you need 1 external-facing IP per host, which makes it expensive to scale since IPv4 space is very limited.
That's the cost of quick-to-implement solution.
If it is possible to have per-host display port range, you could work this limitation around by setting non-overlapping ranges for each host and use a single proxy or DNAT machine that would decide which port to forward based on the range.
I am a colleague of Ewoud, and want to explain a bit more about how we currently have implemented this. All our virtualization hosts, but also the manager only live in the internal network. We have written a webapplication that is a self-service portal for our customers. This webapplication lives on a host that is publicly reachable. This host can also reach the virtualization servers on the internal network. Now for all actions except for viewing a console the webhost only needs to access the api, so what happens when a user wants to view the console (we currently use vnc): On the webhost we have reserved a number of ports. Api request is made to get the host/port, and we set the ticket (vnc password). We create a tunnel (currently use socat, but can of course also be DNAT or any kind of proxy) that connects one of the free ports on the external webhost to the host/port combo we got back from the api. This is a very simple implementation, but it works well in our experience.
For added points you can make the proxy smarter, things like handling vm migrations and maybe adding websockets support for a html5 spice client ;)
the new remote-viewer client no supports a tunneled connection through a proxy like squid. It's not socks or http it's just a tunneled IP connection but will address a number of issues The plan is to add support for this into 3.2 Aic
Kind regards, Sander
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@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
Simon.
Thanks, michal
_______________________________________________ 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
--------------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">http://wiki.ovirt.org/wiki/Features/Display_Address_Override</a> 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://en.wikipedia.org/wiki/Proxy_auto-config</a><br> <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">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </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">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </pre> </blockquote> <br> </body> </html> --------------030300080707090501020601--
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Simon Grinberg" <simon@redhat.com>, "Michal Skrivanek" <michal.skrivanek@redhat.com> Cc: engine-devel@ovirt.org Sent: Sunday, November 11, 2012 11:45:34 AM Subject: Re: [Engine-devel] SPICE IP override
On 11/07/2012 10:52 AM, Simon Grinberg wrote:
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@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).
If I'm reading this correctly the engine should prepare a URL with a PAC script for the Spice client, where the spice client should connect basea on the info in the PAC file. It's still means that we need to provide both internal and external connection option (just through PAC file). Nice.
Simon.
Thanks,
michal
_______________________________________________
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
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.skrivanek@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).
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...?
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: "Simon Grinberg" <simon@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.skrivanek@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).
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?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/15/2012 06:13 AM, Andrew Cathrow wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: "Simon Grinberg" <simon@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.skrivanek@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
On 11/15/2012 06:10 AM, Itamar Heim wrote:
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.skrivanek@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).
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...?
I would actually encourage the customers to use their own corporate PAC and add the information to it. Y.
On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
On 11/15/2012 06:10 AM, Itamar Heim wrote:
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.skrivanek@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).
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...?
I would actually encourage the customers to use their own corporate PAC and add the information to it.
so you are suggesting that there is no need at all to deal with proxy definition/configuration at ovirt engine/user portal level?
----- Original Message -----
On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
On 11/15/2012 06:10 AM, Itamar Heim wrote:
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.skrivanek@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).
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...?
I would actually encourage the customers to use their own corporate PAC and add the information to it.
so you are suggesting that there is no need at all to deal with proxy definition/configuration at ovirt engine/user portal level?
I expect the admin/user portal to send the result of the PAC processing to the Spice client. I don't think the Spice client should execute the PAC (it's a Javascript...). Y.
On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
----- Original Message -----
On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
On 11/15/2012 06:10 AM, Itamar Heim wrote:
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.skrivanek@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).
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...?
I would actually encourage the customers to use their own corporate PAC and add the information to it.
so you are suggesting that there is no need at all to deal with proxy definition/configuration at ovirt engine/user portal level?
I expect the admin/user portal to send the result of the PAC processing to the Spice client. I don't think the Spice client should execute the PAC (it's a Javascript...).
ok, so no engine, but just client side support for PAC?
On 11/15/2012 09:35 AM, Itamar Heim wrote:
On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
----- Original Message -----
On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
On 11/15/2012 06:10 AM, Itamar Heim wrote:
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.skrivanek@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).
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...?
I would actually encourage the customers to use their own corporate PAC and add the information to it.
so you are suggesting that there is no need at all to deal with proxy definition/configuration at ovirt engine/user portal level?
I expect the admin/user portal to send the result of the PAC processing to the Spice client. I don't think the Spice client should execute the PAC (it's a Javascript...).
ok, so no engine, but just client side support for PAC?
Exactly. And of course, Spice protocol changes, without which all this effort is nice, but incomplete. Y.
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Simon Grinberg" <simon@redhat.com>, engine-devel@ovirt.org Sent: Thursday, November 15, 2012 10:07:02 AM Subject: Re: [Engine-devel] SPICE IP override
On 11/15/2012 09:35 AM, Itamar Heim wrote:
On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
----- Original Message -----
On 11/15/2012 08:33 AM, Yaniv Kaul wrote:
On 11/15/2012 06:10 AM, Itamar Heim wrote:
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.skrivanek@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...?
I would actually encourage the customers to use their own corporate PAC and add the information to it.
so you are suggesting that there is no need at all to deal with proxy definition/configuration at ovirt engine/user portal level?
I expect the admin/user portal to send the result of the PAC processing to the Spice client. I don't think the Spice client should execute the PAC (it's a Javascript...).
And live migration? I don't completely understand how you can avoid executing the PAC file if the destination host is provided by Qemu (client_migrate_info) unless I'm confusing with something else and it is the web client that delivers this info on migration. P.S., If it is Qemu, then I don't see the current feature page accounting for that - IE, the hosts should also be informed on this override IP
ok, so no engine, but just client side support for PAC?
Exactly. And of course, Spice protocol changes, without which all this effort is nice, but incomplete. Y.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/15/2012 10:33 AM, Simon Grinberg wrote:
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Simon Grinberg" <simon@redhat.com>, engine-devel@ovirt.org Sent: Thursday, November 15, 2012 10:07:02 AM Subject: Re: [Engine-devel] SPICE IP override
On 11/15/2012 09:35 AM, Itamar Heim wrote:
On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
On 11/15/2012 06:10 AM, Itamar Heim wrote: > 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.skrivanek@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...? I would actually encourage the customers to use their own corporate PAC and add the information to it. so you are suggesting that there is no need at all to deal with
On 11/15/2012 08:33 AM, Yaniv Kaul wrote: proxy definition/configuration at ovirt engine/user portal level? I expect the admin/user portal to send the result of the PAC
----- Original Message ----- processing to the Spice client. I don't think the Spice client should execute the PAC (it's a Javascript...). And live migration?
Read my email: "And of course, Spice protocol changes"
I don't completely understand how you can avoid executing the PAC file if the destination host is provided by Qemu (client_migrate_info) unless I'm confusing with something else and it is the web client that delivers this info on migration.
I'm not against executing the PAC. It just requires a javascript engine, which is a bit of an overkill for Spice client to start working with, no? I'm aware there is a critical gap with the Spice protocol, but all I'm saying is that any other idea you'll come up with to get the topology right is going to be a rewrite of the PAC idea. You will need to define the topology, and you'll need to lookup your current location against it. This is what PAC does. A Spice proxy would probably be able to solve the Spice protocol issue, as we expect the proxy to handle the host hand-over when migration happens, I reckon.
P.S., If it is Qemu, then I don't see the current feature page accounting for that - IE, the hosts should also be informed on this override IP
Why? A host is rarely aware it is behind NAT. If it's because of the protocol issue, the protocol has to be changed. Y.
ok, so no engine, but just client side support for PAC? Exactly. And of course, Spice protocol changes, without which all this effort is nice, but incomplete. Y.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: engine-devel@ovirt.org, "Itamar Heim" <iheim@redhat.com> Sent: Thursday, November 15, 2012 10:42:19 AM Subject: Re: [Engine-devel] SPICE IP override
On 11/15/2012 10:33 AM, Simon Grinberg wrote:
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Simon Grinberg" <simon@redhat.com>, engine-devel@ovirt.org Sent: Thursday, November 15, 2012 10:07:02 AM Subject: Re: [Engine-devel] SPICE IP override
On 11/15/2012 09:35 AM, Itamar Heim wrote:
On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
On 11/15/2012 08:33 AM, Yaniv Kaul wrote: > On 11/15/2012 06:10 AM, Itamar Heim wrote: >> 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.skrivanek@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...? > I would actually encourage the customers to use their own > corporate > PAC > and add the information to it. so you are suggesting that there is no need at all to deal with proxy definition/configuration at ovirt engine/user portal level? I expect the admin/user portal to send the result of the PAC
----- Original Message ----- processing to the Spice client. I don't think the Spice client should execute the PAC (it's a Javascript...). And live migration?
Read my email: "And of course, Spice protocol changes"
I don't completely understand how you can avoid executing the PAC file if the destination host is provided by Qemu (client_migrate_info) unless I'm confusing with something else and it is the web client that delivers this info on migration.
I'm not against executing the PAC. It just requires a javascript engine, which is a bit of an overkill for Spice client to start working with, no? I'm aware there is a critical gap with the Spice protocol, but all I'm saying is that any other idea you'll come up with to get the topology right is going to be a rewrite of the PAC idea. You will need to define the topology, and you'll need to lookup your current location against it. This is what PAC does.
A Spice proxy would probably be able to solve the Spice protocol issue, as we expect the proxy to handle the host hand-over when migration happens, I reckon.
P.S., If it is Qemu, then I don't see the current feature page accounting for that - IE, the hosts should also be informed on this override IP
Why? A host is rarely aware it is behind NAT. If it's because of the protocol issue, the protocol has to be changed.
I'm referring to the current feature page as is (taking out the rest of the discussion): It lacks solution for migration: 1. You have host A, and B, both with overridden IP set 2. On initial connect the browser provides the connection details using host A 'override IP' settings 3. VM Migrates from A to B 4. Now it's Qemu providing the destination connection details - it will provide the internal IP of host B Connection breaks !!! Again, unless I'm missing something and live migration destination is provided by the web client/engine to the spice client (somehow)
Y.
ok, so no engine, but just client side support for PAC? Exactly. And of course, Spice protocol changes, without which all this effort is nice, but incomplete. Y.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Simon Grinberg píše v Čt 15. 11. 2012 v 03:52 -0500:
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: engine-devel@ovirt.org, "Itamar Heim" <iheim@redhat.com> Sent: Thursday, November 15, 2012 10:42:19 AM Subject: Re: [Engine-devel] SPICE IP override
On 11/15/2012 10:33 AM, Simon Grinberg wrote:
----- Original Message -----
From: "Yaniv Kaul" <ykaul@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Simon Grinberg" <simon@redhat.com>, engine-devel@ovirt.org Sent: Thursday, November 15, 2012 10:07:02 AM Subject: Re: [Engine-devel] SPICE IP override
On 11/15/2012 09:35 AM, Itamar Heim wrote:
On 11/15/2012 09:06 AM, Yaniv Kaul wrote:
----- Original Message ----- > On 11/15/2012 08:33 AM, Yaniv Kaul wrote: >> On 11/15/2012 06:10 AM, Itamar Heim wrote: >>> 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.skrivanek@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...? >> I would actually encourage the customers to use their own >> corporate >> PAC >> and add the information to it. > so you are suggesting that there is no need at all to deal with > proxy > definition/configuration at ovirt engine/user portal level? I expect the admin/user portal to send the result of the PAC processing to the Spice client. I don't think the Spice client should execute the PAC (it's a Javascript...). And live migration?
Read my email: "And of course, Spice protocol changes"
I don't completely understand how you can avoid executing the PAC file if the destination host is provided by Qemu (client_migrate_info) unless I'm confusing with something else and it is the web client that delivers this info on migration.
I'm not against executing the PAC. It just requires a javascript engine, which is a bit of an overkill for Spice client to start working with, no? I'm aware there is a critical gap with the Spice protocol, but all I'm saying is that any other idea you'll come up with to get the topology right is going to be a rewrite of the PAC idea. You will need to define the topology, and you'll need to lookup your current location against it. This is what PAC does.
A Spice proxy would probably be able to solve the Spice protocol issue, as we expect the proxy to handle the host hand-over when migration happens, I reckon.
P.S., If it is Qemu, then I don't see the current feature page accounting for that - IE, the hosts should also be informed on this override IP
Why? A host is rarely aware it is behind NAT. If it's because of the protocol issue, the protocol has to be changed.
I'm referring to the current feature page as is (taking out the rest of the discussion): It lacks solution for migration: 1. You have host A, and B, both with overridden IP set 2. On initial connect the browser provides the connection details using host A 'override IP' settings 3. VM Migrates from A to B 4. Now it's Qemu providing the destination connection details - it will provide the internal IP of host B
Connection breaks !!!
Again, unless I'm missing something and live migration destination is provided by the web client/engine to the spice client (somehow)
It is not and your concern is 100% valid. CCing spice-devel. David
Y.
ok, so no engine, but just client side support for PAC? Exactly. And of course, Spice protocol changes, without which all this effort is nice, but incomplete. 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
-- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
On 11/06/2012 10:39 PM, Michal Skrivanek wrote:
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...
Thanks, michal
please note users don't see/get the host entities, so REST API should provide this info under the vm display element.
participants (8)
-
Andrew Cathrow -
David Jaša -
Ewoud Kohl van Wijngaarden -
Itamar Heim -
Michal Skrivanek -
Sander Hoentjen -
Simon Grinberg -
Yaniv Kaul