[Lxc-users] restricting container visible cpus
daniel.lezcano at free.fr
Sun Mar 14 23:33:10 UTC 2010
> Apologies for the delay - I've just got to looking at the procfs
Apologies for the delay too, I just figure out, my answer was still in
the draft folder :s
>> It's for the moment very experimental, it's a prototype:
>> IMO, the code is easy to follow.
>> The fuse in mounted in the container but the code expect to share the
> It needs access to /dev/fuse, and the group mounted. One side effect
> seems to be that if no memory limits are set you'll get the default
> setting for memory.limit_in_bytes rather than the amount of ram in the
> system in /proc/meminfo.
> I can easily fix that, and implement some other files like cpuinfo.
> Before I dive in however;
> In the readme you mention;
> "This code is *not* intended to be integrated to lxc, at least under
> this form, fuse is too heavy and forks too much, for this reason a
> single daemon on the host is better."
> Would you mind expanding on that?Do you have something specific in
Not really. I think we should create a single daemon on the host
providing services for the container, but there is the isolation
preventing us to do that easily, so I don't have yet a clear idea of how
to do that.
The af_unix socket will be shared across namespaces soon, maybe this is
something we can use to have lxc to collaborate with a fuse daemon
running on the host.
The lxc component is still under development and I try to add
enhancement but keep polishing the code always.
The integration with new kernel features and the kernel development /
followup / testing / discussion takes me some time. For these reasons, I
don't want to handle a new component like "procfs" for now being more
time consuming, so I hope someone will take care of the /proc
virtualization and will enhance it in parallel of lxc (of course usable
from it) and when it is mature, light and ready, we plan how to
integrate it in the lxc code.
> The current way of mounting fuse somewhere else (/tmp/dir) and
> doing a bind mount of /tmp/dir back over /proc seems a little clumsy.
Yes, but fuse needs /proc, so if we mount the /proc first, fuse fails.
> If there's a better way, either a daemon on the host, or a kernel
> module, I'll happily start down that road given a couple of hints.
I think the /proc virtualization can not be handled by a kernel module,
and the kernel itself should not take care of that. The paradigm for the
container is clear, and was stated at the container development beginning :
containers are not virtual machine. The kernel will never virtualize
physical resources for a container.
This is problematic for at least the cpu and the memory, as there are
applications doing cpu affinity setting or memory tuning depending of
the memory available on the host.
I discussed about the /proc virtualization a few month ago with the
kernel community and we all agree using fuse to override the /proc
userspace view is a good choice. IMO any attempt to modify /proc in the
kernel will result in a fatal NACK from the community.
Some steps, from my pov :
* how to make, let's call it "fuse-procfs", working with a chrooted
* make it configurable (choose the files to be hidden in the container)
I hope that helps.
More information about the lxc-users