On 07/26/2012 05:55 PM, Alon Bar-Lev wrote:

On Thu, Jul 26, 2012 at 5:51 PM, Ewoud Kohl van Wijngaarden <ewoud+ovirt@kohlvanwijngaarden.nl> wrote:

...

...

I am looking at adding VNC support in ovirt. What does the community think? Ideas, suggestions, comments? By that I think you mean adding VNC support to the java-based web interface. In that case +1. I can recommend noVNC[1], but you do need a websockets proxy. I can recommend VNCAuthProxy[2] as a programmable

On Thu, Jul 26, 2012 at 07:36:43AM -0700, snmishra@linux.vnet.ibm.com wrote: proxy with a JSON control channel. On the plus side all dependencies are in fedora/epel. Downside is no IPv6 support. Maybe you can also write a pure java implementation integrate this into the engine itself?

[1]: http://kanaka.github.com/noVNC/ [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/

Or launch client program via MIME bindings[1] both for Vnc and Spice. Not as neat as "noVnc" but will work in most scenarios, without having to maintain the actual console implementation.

what would users need to do at client side to configure the mime bindings?

----- Original Message -----

From: "Michal Skrivanek" <michal.skrivanek@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt@kohlvanwijngaarden.nl>, engine-devel@ovirt.org Sent: Friday, July 27, 2012 12:01:32 PM Subject: Re: [Engine-devel] Adding VNC support

On Jul 26, 2012, at 16:55 , Alon Bar-Lev wrote:

...

On Thu, Jul 26, 2012 at 5:51 PM, Ewoud Kohl van Wijngaarden <ewoud+ovirt@kohlvanwijngaarden.nl> wrote:

...

...

I am looking at adding VNC support in ovirt. What does the community think? Ideas, suggestions, comments? By that I think you mean adding VNC support to the java-based web interface. In that case +1. I can recommend noVNC[1], but you do need a websockets proxy. I can recommend VNCAuthProxy[2] as a

On Thu, Jul 26, 2012 at 07:36:43AM -0700, snmishra@linux.vnet.ibm.com wrote: programmable proxy with a JSON control channel. On the plus side all dependencies are in fedora/epel. Downside is no IPv6 support. Maybe you can also write a pure java implementation integrate this into the engine itself?

[1]: http://kanaka.github.com/noVNC/ [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/

Or launch client program via MIME bindings[1] both for Vnc and Spice. Not as neat as "noVnc" but will work in most scenarios, without having to maintain the actual console implementation. I would think there are many people out there who are not able to use current spice client, or not willing to(hate switching from chrome to firefox:-) Sure they can set up things manually but it would be way more convenient to allow a simple external launch of their VNC client of choice

Right. Exactly what I think. In time the installation of the client can set up the MIME binding automatically.

...

[1] https://bugzilla.redhat.com/show_bug.cgi?id=843410 _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

----- Original Message -----

From: "Itamar Heim" <iheim@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Michal Skrivanek" <michal.skrivanek@redhat.com>, engine-devel@ovirt.org Sent: Saturday, July 28, 2012 7:36:17 AM Subject: Re: [Engine-devel] Adding VNC support

On 07/28/2012 03:31 AM, Alon Bar-Lev wrote:

...

----- Original Message -----

...

From: "Michal Skrivanek" <michal.skrivanek@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt@kohlvanwijngaarden.nl>, engine-devel@ovirt.org Sent: Friday, July 27, 2012 12:01:32 PM Subject: Re: [Engine-devel] Adding VNC support

On Jul 26, 2012, at 16:55 , Alon Bar-Lev wrote:

...

On Thu, Jul 26, 2012 at 5:51 PM, Ewoud Kohl van Wijngaarden <ewoud+ovirt@kohlvanwijngaarden.nl> wrote:

...

...

I am looking at adding VNC support in ovirt. What does the community think? Ideas, suggestions, comments? By that I think you mean adding VNC support to the java-based web interface. In that case +1. I can recommend noVNC[1], but you do need a websockets proxy. I can recommend VNCAuthProxy[2] as a

On Thu, Jul 26, 2012 at 07:36:43AM -0700, snmishra@linux.vnet.ibm.com wrote: programmable proxy with a JSON control channel. On the plus side all dependencies are in fedora/epel. Downside is no IPv6 support. Maybe you can also write a pure java implementation integrate this into the engine itself?

[1]: http://kanaka.github.com/noVNC/ [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/

Or launch client program via MIME bindings[1] both for Vnc and Spice. Not as neat as "noVnc" but will work in most scenarios, without having to maintain the actual console implementation. I would think there are many people out there who are not able to use current spice client, or not willing to(hate switching from chrome to firefox:-) Sure they can set up things manually but it would be way more convenient to allow a simple external launch of their VNC client of choice

Right. Exactly what I think. In time the installation of the client can set up the MIME binding automatically.

that means patching all the vnc clients iiuc, to set mime for multiple browser versions?

At first we provide support at the engine side, and user get it manually: User will get a dialog: "(o) Open File" "( ) Download" When selecting "Open File" he will need to choose a program. Initially we will provide programs (scripts) for both vnc and spice. Then after user are satisfied we offer these programs to the appropriate upstream. Best case: will be accepted (maybe with modifications). Worse case: will be rejected so we provide engine-console package to our users with these programs. Regards, Alon.

----- Original Message -----

From: "Simon Grinberg" <simon@redhat.com> To: snmishra@linux.vnet.ibm.com Cc: engine-devel@ovirt.org Sent: Thursday, July 26, 2012 10:57:23 AM Subject: Re: [Engine-devel] Adding VNC support

----- Original Message -----

...

From: snmishra@linux.vnet.ibm.com To: engine-devel@ovirt.org Sent: Thursday, July 26, 2012 5:36:43 PM Subject: [Engine-devel] Adding VNC support

Hi,

I am looking at adding VNC support in ovirt. What does the community think? Ideas, suggestions, comments?

If you can, I think it will be welcomed.

The problem (as I recall, and I may be wrong) is that there is no VNC xpi available, thus connection is not possible directly through the portal. If you want to use VNC it is possible today, you'll have to set the ticket/password via the API and the connect with VNC viewer.

With that said, my personal opinion is that it's not necessary except for those who really like VNC. SPICE has an available XPI, and when you don't use the Spice Drivers the default mode is in par with VNC. So why to bother?

if you don't have a spice client installed, if you have really bad bandwidth, if you're on a Mac, iOS, etc........

...

Thanks Sharad Mishra IBM

_______________________________________________ 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

I've already expressed my inclination, but…:-) On Jul 31, 2012, at 08:18 , Itamar Heim wrote:

On 07/26/2012 05:36 PM, snmishra@linux.vnet.ibm.com wrote:

...

Hi,

I am looking at adding VNC support in ovirt. What does the community think? Ideas, suggestions, comments?

so to sum this up: 1. there is the new dialog to open vnc manually. http://gerrit.ovirt.org/#/c/4790/ helps, but not really that friendly. In fact it sort of suggests we are not able to achieve a simple task of running an external app:)

2. Alon suggested it should be allowed to open this dialog for spice as well, not only for vnc.

3. Alon also suggested to have a launch button on that window (or parallel to it) which will try to launch vnc or spice by returning a specific mime type response, allowing client to choose the vnc/spice client to run for this mime type, and passing command line parameters to it in the mime type reply. I think this is reasonable result for little effort. It would allow to seamlessly open the connection for all other platforms we do not support today, Mac, iOS, it's quite easy to get a VNC on almost any platform as opposed to limited spiceclient support.

4. provide a vnc xpi/activex wrappers to allow launching it via web browsers like spice main limitation of this compared to novnc is you need to do this for every browser/platform. more effort than #3, too many browsers out there, and you have to install a plugin

5. novnc 5.1 novnc client - i'd start with the one recently pushed to fedora. https://bugzilla.redhat.com/show_bug.cgi?id=822187

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

5.2.2 use the python based one from: https://bugzilla.redhat.com/show_bug.cgi?id=822187

5.2.3 look at a java based websocket solution, assuming easier to deploy it as part of webadmin/user portal war than another service (requires a bit of research) looking forward user portal and webadmin would be deployed on multiple hosts, so a websockets would need to be deployed next to them.

from the little i looked at, the various websocket implementations are mostly nascent and are not scaleable/robust/etc. I'd love to be proven wrong, and worth playing with them a bit to measure that.

and novnc client is still far less common than vnc. Having it in Fedora doesn't help much.

6. spice.html5 while very nascent - worth mentioning on this thread and trying to take a look: http://www.spice-space.org/page/Html5

more effort than #3, browser support questionable. I'd have doubts about performance on mobile devices even in the future

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

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

On Tue, Jul 31, 2012 at 01:44:41PM -0700, snmishra@linux.vnet.ibm.com wrote:

Quoting Ewoud Kohl van Wijngaarden <ewoud+ovirt@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@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.

----- Original Message -----

From: "Itamar Heim" <iheim@redhat.com> To: snmishra@linux.vnet.ibm.com Cc: engine-devel@ovirt.org Sent: Tuesday, July 31, 2012 2:18:50 AM Subject: Re: [Engine-devel] Adding VNC support

On 07/26/2012 05:36 PM, snmishra@linux.vnet.ibm.com wrote:

...

Hi,

I am looking at adding VNC support in ovirt. What does the community think? Ideas, suggestions, comments?

so to sum this up: 1. there is the new dialog to open vnc manually. http://gerrit.ovirt.org/#/c/4790/

2. Alon suggested it should be allowed to open this dialog for spice as well, not only for vnc.

3. Alon also suggested to have a launch button on that window (or parallel to it) which will try to launch vnc or spice by returning a specific mime type response, allowing client to choose the vnc/spice client to run for this mime type, and passing command line parameters to it in the mime type reply.

4. provide a vnc xpi/activex wrappers to allow launching it via web browsers like spice main limitation of this compared to novnc is you need to do this for every browser/platform.

5. novnc 5.1 novnc client - i'd start with the one recently pushed to fedora. https://bugzilla.redhat.com/show_bug.cgi?id=822187

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

One of the requirements we want to eliminate is the need for clients to connect directly to the hypervisor. I think the novnc server should be externally hosted not part of qemu

5.2.2 use the python based one from: https://bugzilla.redhat.com/show_bug.cgi?id=822187

+1

5.2.3 look at a java based websocket solution, assuming easier to deploy it as part of webadmin/user portal war than another service (requires a bit of research) looking forward user portal and webadmin would be deployed on multiple hosts, so a websockets would need to be deployed next to them.

from the little i looked at, the various websocket implementations are mostly nascent and are not scaleable/robust/etc. I'd love to be proven wrong, and worth playing with them a bit to measure that.

6. spice.html5 while very nascent - worth mentioning on this thread and trying to take a look: http://www.spice-space.org/page/Html5 _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

Quoting Itamar Heim <iheim@redhat.com>:

On 07/26/2012 05:36 PM, snmishra@linux.vnet.ibm.com wrote:

...

Hi,

I am looking at adding VNC support in ovirt. What does the community think? Ideas, suggestions, comments?

so to sum this up: 1. there is the new dialog to open vnc manually. http://gerrit.ovirt.org/#/c/4790/

good

2. Alon suggested it should be allowed to open this dialog for spice as well, not only for vnc.

+1

3. Alon also suggested to have a launch button on that window (or parallel to it) which will try to launch vnc or spice by returning a specific mime type response, allowing client to choose the vnc/spice client to run for this mime type, and passing command line parameters to it in the mime type reply.

+1 I like the idea of being able to launch vnc and spice from the same place.

4. provide a vnc xpi/activex wrappers to allow launching it via web browsers like spice main limitation of this compared to novnc is you need to do this for every browser/platform.

I like the noVNC option better since most modern web browsers support the canvas element of HTML 5. With noVNC we don't have to port to other platforms/browsers.

5. novnc 5.1 novnc client - i'd start with the one recently pushed to fedora. https://bugzilla.redhat.com/show_bug.cgi?id=822187

+1 that is an added advantage.

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

5.2.2 use the python based one from: https://bugzilla.redhat.com/show_bug.cgi?id=822187

5.2.3 look at a java based websocket solution, assuming easier to deploy it as part of webadmin/user portal war than another service (requires a bit of research) looking forward user portal and webadmin would be deployed on multiple hosts, so a websockets would need to be deployed next to them.

I can see myself going either way with java or python based websockets. -Sharad Mishra

from the little i looked at, the various websocket implementations are mostly nascent and are not scaleable/robust/etc. I'd love to be proven wrong, and worth playing with them a bit to measure that.

6. spice.html5 while very nascent - worth mentioning on this thread and trying to take a look: http://www.spice-space.org/page/Html5