Re: [Engine-devel] SPICE IP override
- Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, November 6, 2012 10:39:58 PM Subject: [Engine-devel] SPICE IP override Hi all, On behalf of Tomas - please check out the proposal for enhancing our SPICE integration to allow to return a custom IP/FQDN instead of the host IP address. http://wiki.ovirt.org/wiki/Features/Display_Address_Override All comments are welcome... My 2 cents, This works under the assumption that all the users are either outside of the organization or inside. But think of some of the following scenarios based on a topology where users in the main office are inside the corporate network while users on remote offices / WAN are on a detached different network on the other side of the NAT / public firewall : With current 'per host override' proposal: 1. Admin from the main office won't be able to access the VM console 2. No Mixed environment, meaning that you have to have designated clusters for remote offices users vs main office users - otherwise connectivity to the console is determined based on scheduler decision, or may break by live migration. 3. Based on #2, If I'm a user travelling between offices I'll have to ask the admin to turn off my VM and move it to internal cluster before I can reconnect My suggestion is to covert this to 'alternative' IP/FQDN sending the spice client both internal fqdn/ip and the alternative. The spice client should detect which is available of the two and auto-connect. This requires enhancement of the spice client, but still solves all the issues raised above (actually it solves about 90% of the use cases I've heard about in the past). Another alternative is for the engine to 'guess' or 'elect' which to use, alternative or main, based on the IP of the client - meaning admin provides the client ranges for providing internal host address vs alternative - but this is more complicated compared for the previous suggestion Thoughts? 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
Re: [Engine-devel] SPICE IP override
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. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] SPICE IP override
- Original Message - From: Itamar Heim ih...@redhat.com To: Simon Grinberg si...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, November 7, 2012 10:46:24 AM Subject: Re: [Engine-devel] SPICE IP override On 11/07/2012 09:52 AM, Simon Grinberg wrote: - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, November 6, 2012 10:39:58 PM Subject: [Engine-devel] SPICE IP override Hi all, On behalf of Tomas - please check out the proposal for enhancing our SPICE integration to allow to return a custom IP/FQDN instead of the host IP address. http://wiki.ovirt.org/wiki/Features/Display_Address_Override All comments are welcome... My 2 cents, This works under the assumption that all the users are either outside of the organization or inside. But think of some of the following scenarios based on a topology where users in the main office are inside the corporate network while users on remote offices / WAN are on a detached different network on the other side of the NAT / public firewall : With current 'per host override' proposal: 1. Admin from the main office won't be able to access the VM console 2. No Mixed environment, meaning that you have to have designated clusters for remote offices users vs main office users - otherwise connectivity to the console is determined based on scheduler decision, or may break by live migration. 3. Based on #2, If I'm a user travelling between offices I'll have to ask the admin to turn off my VM and move it to internal cluster before I can reconnect My suggestion is to covert this to 'alternative' IP/FQDN sending the spice client both internal fqdn/ip and the alternative. The spice client should detect which is available of the two and auto-connect. This requires enhancement of the spice client, but still solves all the issues raised above (actually it solves about 90% of the use cases I've heard about in the past). Another alternative is for the engine to 'guess' or 'elect' which to use, alternative or main, based on the IP of the client - meaning admin provides the client ranges for providing internal host address vs alternative - but this is more complicated compared for the previous suggestion Thoughts? i think this is over complicating things. I'd expect someone that wants to handle internal and external differently to use DNS, and resolve the DNS differently for external and internal clients. That will not necessarily solve the issue - what about WAN users from home? the DNS is not under their control - they need redirection to the public facing NAT servers. + 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] SPICE IP override
On 11/07/2012 10:52 AM, Simon Grinberg wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Simon Grinberg si...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, November 7, 2012 10:46:24 AM Subject: Re: [Engine-devel] SPICE IP override On 11/07/2012 09:52 AM, Simon Grinberg wrote: - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, November 6, 2012 10:39:58 PM Subject: [Engine-devel] SPICE IP override Hi all, On behalf of Tomas - please check out the proposal for enhancing our SPICE integration to allow to return a custom IP/FQDN instead of the host IP address. http://wiki.ovirt.org/wiki/Features/Display_Address_Override All comments are welcome... My 2 cents, This works under the assumption that all the users are either outside of the organization or inside. But think of some of the following scenarios based on a topology where users in the main office are inside the corporate network while users on remote offices / WAN are on a detached different network on the other side of the NAT / public firewall : With current 'per host override' proposal: 1. Admin from the main office won't be able to access the VM console 2. No Mixed environment, meaning that you have to have designated clusters for remote offices users vs main office users - otherwise connectivity to the console is determined based on scheduler decision, or may break by live migration. 3. Based on #2, If I'm a user travelling between offices I'll have to ask the admin to turn off my VM and move it to internal cluster before I can reconnect My suggestion is to covert this to 'alternative' IP/FQDN sending the spice client both internal fqdn/ip and the alternative. The spice client should detect which is available of the two and auto-connect. This requires enhancement of the spice client, but still solves all the issues raised above (actually it solves about 90% of the use cases I've heard about in the past). Another alternative is for the engine to 'guess' or 'elect' which to use, alternative or main, based on the IP of the client - meaning admin provides the client ranges for providing internal host address vs alternative - but this is more complicated compared for the previous suggestion Thoughts? i think this is over complicating things. I'd expect someone that wants to handle internal and external differently to use DNS, and resolve the DNS differently for external and internal clients. That will not necessarily solve the issue - what about WAN users from home? the DNS is not under their control - they need redirection to the public facing NAT servers. if a public service, not relevant. if a private service, i expect they would be using a VPN, with dns resolution provided by the organization for external vpn users, if they need to resolve IPs differently internally and externally. + 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
Re: [Engine-devel] SPICE IP override
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.skriva...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, November 6, 2012 10:39:58 PM Subject: [Engine-devel] SPICE IP override Hi all, On behalf of Tomas - please check out the proposal for enhancing our SPICE integration to allow to return a custom IP/FQDN instead of the host IP address. http://wiki.ovirt.org/wiki/Features/Display_Address_Override All comments are welcome... My 2 cents, This works under the assumption that all the users are either outside of the organization or inside. But think of some of the following scenarios based on a topology where users in the main office are inside the corporate network while users on remote offices / WAN are on a detached different network on the other side of the NAT / public firewall : With current 'per host override' proposal: 1. Admin from the main office won't be able to access the VM console 2. No Mixed environment, meaning that you have to have designated clusters for remote offices users vs main office users - otherwise connectivity to the console is determined based on scheduler decision, or may break by live migration. 3. Based on #2, If I'm a user travelling between offices I'll have to ask the admin to turn off my VM and move it to internal cluster before I can reconnect My suggestion is to covert this to 'alternative' IP/FQDN sending the spice client both internal fqdn/ip and the alternative. The spice client should detect which is available of the two and auto-connect. This requires enhancement of the spice client, but still solves all the issues raised above (actually it solves about 90% of the use cases I've heard about in the past). Another alternative is for the engine to 'guess' or 'elect' which to use, alternative or main, based on the IP of the client - meaning admin provides the client ranges for providing internal host address vs alternative - but this is more complicated compared for the previous suggestion Thoughts? I 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] SPICE IP override
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.skriva...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, November 6, 2012 10:39:58 PM Subject: [Engine-devel] SPICE IP override Hi all, On behalf of Tomas - please check out the proposal for enhancing our SPICE integration to allow to return a custom IP/FQDN instead of the host IP address. http://wiki.ovirt.org/wiki/Features/Display_Address_Override All comments are welcome... My 2 cents, This works under the assumption that all the users are either outside of the organization or inside. But think of some of the following scenarios based on a topology where users in the main office are inside the corporate network while users on remote offices / WAN are on a detached different network on the other side of the NAT / public firewall : With current 'per host override' proposal: 1. Admin from the main office won't be able to access the VM console 2. No Mixed environment, meaning that you have to have designated clusters for remote offices users vs main office users - otherwise connectivity to the console is determined based on scheduler decision, or may break by live migration. 3. Based on #2, If I'm a user travelling between offices I'll have to ask the admin to turn off my VM and move it to internal cluster before I can reconnect My suggestion is to covert this to 'alternative' IP/FQDN sending the spice client both internal fqdn/ip and the alternative. The spice client should detect which is available of the two and auto-connect. This requires enhancement of the spice client, but still solves all the issues raised above (actually it solves about 90% of the use cases I've heard about in the past). Another alternative is for the engine to 'guess' or 'elect' which to use, alternative or main, based on the IP of the client - meaning admin provides the client ranges for providing internal host address vs alternative - but this is more complicated compared for the previous suggestion Thoughts? I 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. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] SPICE IP override
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.skriva...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, November 6, 2012 10:39:58 PM Subject: [Engine-devel] SPICE IP override Hi all, On behalf of Tomas - please check out the proposal for enhancing our SPICE integration to allow to return a custom IP/FQDN instead of the host IP address. http://wiki.ovirt.org/wiki/Features/Display_Address_Override All comments are welcome... My 2 cents, This works under the assumption that all the users are either outside of the organization or inside. But think of some of the following scenarios based on a topology where users in the main office are inside the corporate network while users on remote offices / WAN are on a detached different network on the other side of the NAT / public firewall : With current 'per host override' proposal: 1. Admin from the main office won't be able to access the VM console 2. No Mixed environment, meaning that you have to have designated clusters for remote offices users vs main office users - otherwise connectivity to the console is determined based on scheduler decision, or may break by live migration. 3. Based on #2, If I'm a user travelling between offices I'll have to ask the admin to turn off my VM and move it to internal cluster before I can reconnect My suggestion is to covert this to 'alternative' IP/FQDN sending the spice client both internal fqdn/ip and the alternative. The spice client should detect which is available of the two and auto-connect. This requires enhancement of the spice client, but still solves all the issues raised above (actually it solves about 90% of the use cases I've heard about in the past). Another alternative is for the engine to 'guess' or 'elect' which to use, alternative or main, based on the IP of the client - meaning admin provides the client ranges for providing internal host address vs alternative - but this is more complicated compared for the previous suggestion Thoughts? I 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. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
