[libvirt] RFC: Increasing number of processes allowed for qemu user

[Jiri Denemark]

On Thu, Mar 03, 2011 at 12:07:12 +0000, Daniel P. Berrange wrote:
> If it were possible to change it on the fly, then I think it could be
> valid to suggest it is libvirt's responsibility. Since ulimits can't be
> changed for the existing QEMU processes though, the only option is to
> change it ahead of time at a host level. The default of 1024 is clearly
> faaar to low for modern systems so, IMHO, someone/thing just needs to
> place a file at /etc/limits.d/qemu.conf to raise it say to 10,000 which
> a modern Linux system can easily cope with.

Right, although it's /etc/security/limits.d/..., but the thing is who/what
should provided that file. Should it be libvirt or host admin or something
else? On one hand, I think it shouldn't be libvirt since it is possible to
change qemu user in /etc/libvirt/qemu.conf and setting such limits should be
done by the host admin. On the other hand, for better out-of-the-box behavior,
we could generate that file according to how libvirt was configured (i.e.,
what the default qemu user is) and install it.

Which of the options do you prefer?

> The original rational for the nproc ulimit is to protect against fork
> bombs, but this is really a terrible solution because it applies at the
> wrong level. To protect against this properly we would want a limit on
> a number of children any single QEMU process can spawn, not a limit on
> the number that the QEMU user can spawn. The obvious places for this is
> a cgroup tunable, which would mesh nicely with the fact that we put each
> QEMU in a dedicated group. Someone has written such a patch before, but
> it was never merged AFAICT:

Yeah, that would ideal for limiting number of process/threads a single domain
can use.

Jirka