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 :|