6:24 p.m.
On Tue, Jul 31, 2012 at 01:44:41PM -0700, snmishra(a)linux.vnet.ibm.com wrote:
Quoting Ewoud Kohl van Wijngaarden
<ewoud+ovirt(a)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(a)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.