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