[Engine-devel] Adding VNC support

[Ewoud Kohl van Wijngaarden]

On Tue, Jul 31, 2012 at 01:44:41PM -0700, snmishra at linux.vnet.ibm.com wrote:
> Quoting Ewoud Kohl van Wijngaarden <ewoud+ovirt at kohlvanwijngaarden.nl>:
> >On Tue, Jul 31, 2012 at 09:44:10AM -0400, Alon Bar-Lev wrote:
> >>Ewoud Kohl van Wijngaarden wrote:
> >>> On Tue, Jul 31, 2012 at 10:09:26AM +0100, Daniel P. Berrange wrote:
> >>> > On Tue, Jul 31, 2012 at 09:18:50AM +0300, Itamar Heim wrote:
> >>> > > On 07/26/2012 05:36 PM, snmishra at linux.vnet.ibm.com wrote:
> >>> > > 5.2 novnc websocket server - i see three options
> >>> > >
> >>> > > 5.2.1 extend qemu to do this, so novnc can connect to it directly
> >>> > > like we do today for vnc/spice
> >>> >
> >>> > I don't think this is a desirable approach. One of the nice
> >>> > benefits
> >>> > you gain from using a websocket proxy is that you only need to have
> >>> > one single TCP port exposed to the internet now. If you put
> >>> > websockets
> >>> > in QEMU itself, you'd be stuck with having to open your firewall to
> >>> > allow 100's of ports. With a separate web proxy, you can even make
> >>> > each QEMU server now use a local UNIX socket for their VNC server,
> >>> > since only the proxy needs to be able to connect. This means that
> >>> > the VNC server would no longer be exposed to random local user
> >>> > access too.
> >>>
> >>> Another benefit of a proxy is that you can run it in a DMZ and not
> >>> have
> >>> to expose all your virtualization hosts to the internet.
> >>
> >>But this way you do expose them :)
> >
> >Since I've worked with VNCAuthProxy I'll explain how that works.
> >
> >First of all it listens on a control port. This can be inside the
> >firewall and has a simple JSON-based protocol. On this control port you
> >can ask it to open a connection on port X to virt-host.example.org:Y.
> >virt-host.example.org can also be behind the firewall and now only port
> >X is exposed to the internet.
>
> I am coming from the libvirt/libvirt-cim world and I don't
> completely follow this discussion. In libvrt-cim (higher level layer
> using libvirt to create and manage VMs), we took the input from user
> on what VNC IP, port, vncpassword etc. the user wants to use to
> access the VM and created a libvirt XML using these user provided
> values. This XML was then passed to libvirt which created the new VM
> and magically set vnc up. The user then opened any VNC viewer of
> their choice to access the VM. If ovirt is using libvirt, why can't
> we use the same magic?

I'm not that familiar with the internals ovirt uses (above experience is
based on ganeti[1]), but libvirt runs on the virtualisation host. Many
users don't want to give those hosts direct internet access for security
reasons.

Think of a cloud provider based on oVirt / RHEV who wants to provide a
console to their customers. AFAIK they Currently have to somehow make
those hosts available and I think oVirt can be configured to use a
separate network but having a proxy might align better with security
policies at the cloud provider. I know my colleagues had to think of a
solution for this because we didn't want to expose our RHEV hosts.