----- 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

Reply via email to