Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Setting vm.max_map_count inside LXD container fails #2206
Setting the vm.max_map_count value inside the container fails. This report is solely on the failure of setting the
The origin for trying to set the
5.0.0alpha4 startup log:
I've opened a bug report with Elasticsearch as well elastic/elasticsearch#19458
Steps to reproduce
Information to attach
Following the instructions from the Elasticsearch docs to set the vm.max_map_count value, writing the new value fails in the container.
Can you do "lxc config set base-elasticsearch raw.lxc lxc.aa_profile=unconfined", then restart the container with "lxc restart base-elasticsearch" and see if it's still a problem?
If it is, it's because that particular key isn't namespaced and/or allowed for unprivileged user use by the kernel.
@stgraber it still is
@pcdummy perfect! setting it on the host is retrieved on the container. The performance issues that this may have, I have no idea.
Ok, so there's nothing we can do about this in LXD itself. If bumping the limit on the host is fine with you, then you can do that. If there is a good reason for the container to be able to do it on its own and it can be demonstrated that allowing unprivileged users (and containers) to change this setting won't cause a security issue, then we may be able to convince someone to write a Linux kernel patch to allow this.
I personally don't expect this to become a user accessible knob. What may be doable is to allow containers to define a value lower than the host though, so similar to what's done in the cgroup subsystem (this may even be tied to the memory cgroup).
In any case, as I said, there's nothing we can do about this in LXD itself as it's purely a kernel limitation, so closing this issue. If you do end up filing a kernel bug/feature request somewhere about this, feel free to leave a comment here so others can find it!