On Thu, Mar 10, 2011 at 11:33:24AM +0000, Daniel P. Berrange wrote:
On Wed, Mar 09, 2011 at 02:20:09PM +0100, Jiri Denemark wrote:
The daemon/libvirtd.limits file (which is supposed to be copied to /etc/security/limits.d/libvirtd.conf) is generated based on --qemu-user option passed at configure time.
The file is intentionally not installed by make install since installing it on distributions with higher or no limit on number of process could actually result in lowering the limit. Packagers may choose whether to install the file or not. It is installed by libvirt.spec for RPM based distributions.
[snip]
Hmm, did you actually test this setup to make sure it works as we expect ? I have this nasty feeling in the back of my mind that the files under /etc/security/limits.d/ are only processed by PAM modules. Since PAM isn't at all involved when libvirt changes UID to 'qemu' to launch QEMU, how does QEMU actually see the increased limit being set ?
Well I've tested this now and confirm that putting a file into /etc/security/limits.d for the 'qemu' user, has absolutely no effect on QEMU as launched by libvirtd.
Something needs to be calling the setrlimit() systemcall for the QEMU process when it is launched and I don't see what is yet ?
Because we don't use PAM, QEMU is just inheriting the limits from libvirtd. For added fun, the limits that libvirtd sees typically differ depending on whether libvirtd was started from a root login shell, or from init. So AFAICT, we have to use setrlimit() if we want to control this. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|