[Lxc-users] restricting container visible cpus

[Daniel Lezcano]

atp wrote:
> Daniel,
>
>  Apologies for the delay - I've just got to looking at the procfs
> tarball.
>   

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:
>> http://lxc.sourceforge.net/download/procfs/procfs.tar.gz
>>
>> IMO, the code is easy to follow.
>>
>> The fuse in mounted in the container but the code expect to share the 
>> rootfs.
>>
>>     
>
>   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. 
>   
Right.
>   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
> mind?
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 
environment.
 * make it configurable (choose the files to be hidden in the container)

I hope that helps.

Thanks
  -- Daniel