[Engine-devel] SPICE IP override

Sat Nov 10 19:56:41 UTC 2012

----- Original Message -----
> From: "Sander Hoentjen" <sander at hoentjen.eu>
> To: engine-devel at 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 at redhat.com>
> > > > > > > To: engine-devel at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 