On Wed, Mar 19, 2014 at 06:41:16PM +0000, Patil, Tushar wrote:

...

We are using KVM hypervisor driver for running OpenStack IaaS. Couple of months back we have reported one security issue [1] in OS. Basically we want to limit on the number of vnc client connections that can be opened by users for a given VM. I know that there is share policy where you can specify "VNC_SHARE_MODE_EXCLUSIVE" share mode. But it only allows one client connection to the vnc console, it will disconnect all previously opened vnc client connections. Since vnc display driver already has the data of client connections, it would be possible to add the logic to limit on the number of client connections.

What we want is the ability to specify threshold how many vnc client connections should be allowed at any given point of time in the domain xml for graphics device (especially for vnc/spice)?

Example <graphics type="vnc" autoport="yes" keymap="en-us" listen="127.0.0.1"/, share-policy="limit-connections", connections="5">

Add support to accept new share policy "limit-connections'. So in the above example, when user tries to open vnc display for the 6th time, then the request should be rejected.

I need your expert opinion in deciding whether it's a good idea to add this support in the vnc/spice display driver or this kind of constraint should be imposed outside libvirt?

Libvirt isn't at all involved in vnc/spice connections. They happen directly between QEMU & the client app, optionally via Nova's proxy service. If QEMU had a setting for such a limit then libvirt could set it, but AFAIK none exists, so there's nothing libvirt can do about this currently. So options are either todo work in QEMU to add this config feature, then wire it into libvirt, or address it in the Nova proxy service.

Thanks for your advice. I will add a new feature request in qemu. After this feature is added to qemu, I will then add a request in libvirt to use the newly added parameters. Thanks and Best Regards, Tushar ______________________________________________________________________ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding