[libvirt] [PATCH] qemu: Support for overriding NPROC limit

[Jiri Denemark]

On Tue, Apr 05, 2011 at 09:28:00 -0600, Eric Blake wrote:
> On 04/05/2011 08:09 AM, Jiri Denemark wrote:
> > This patch adds max_processes option to qemu.conf which can be used to
> > override system default limit on number of processes that are allowed to
> > be running for qemu user.
> > ---
> >  src/qemu/libvirtd_qemu.aug      |    3 +++
> >  src/qemu/qemu.conf              |    7 +++++++
> >  src/qemu/qemu_conf.c            |    4 ++++
> >  src/qemu/qemu_conf.h            |    2 ++
> >  src/qemu/qemu_process.c         |   24 ++++++++++++++++++++++++
> >  src/qemu/test_libvirtd_qemu.aug |    4 ++++
> >  6 files changed, 44 insertions(+), 0 deletions(-)
> > @@ -1821,6 +1842,9 @@ static int qemuProcessHook(void *data)
> >  {
> >      struct qemuProcessHookData *h = data;
> >  
> > +    if (qemuProcessLimits(h->driver) < 0)
> > +        return -1;
> 
> Which UID is in effect at this point?  While setrlimit() adjusts an
> inherited value, I'm a bit worried that tracks different limits per uid,
> and if the call is made while the real uid is root instead of qemu, then
> we might be affecting the wrong limit.  Does this call need to be
> delayed until after the virSecurityManagerSetProcessLabel, or after we
> are sure that we have changed identities?

Actually it's important that we call setrlimit() before dropping root
privileges since only such process can increase the limit.

The NPROC limit is pretty confusing since it logically doesn't fit in
setrlimit and by it gets unnatural behavior as a result of it being set via
setrlimit. It only affects the limit seen by current process which will soon
be executing qemu code.

Jirka