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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list