[Lxc-users] restricting container visible cpus

Daniel Lezcano daniel.lezcano at free.fr
Mon Feb 1 10:27:40 UTC 2010

atp wrote:
> Hi,
>> There is a /proc virtualization layer prototype with fuse which needs to 
>> be enhanced but it's not for the short term as there are several issues 
>> with the container itself to be solved before adding it.
>> But any volunteer is welcome ;)
>   I hacked up a quick modification to arch/x86/kernel/cpu/proc.c on
> friday that restricted the view of /proc/cpuinfo to only those processes
> in current->cpus_allowed as a quick way of testing if that approach did
> what I wanted. There's bugs remaining, and I'm not 100% sure that its 
> the correct approach, but if anyone's interested let me know. 

I already proposed this approach but it was rightfully rejected. I think 
that will be a total mess to handle that from the kernel because if you 
add the cpus, after you will need the memory, the swap, hide the content 
of some files etc ...

For this reason, it was proposed to use a fuse filesystem on top of 
/proc to override the information, there is a prototype here:

At present it overrides the /proc/meminfo and hide some files.
Adding /proc/cpuinfo is trivial.

If you are interested, I can send you a tarball.
>   Anyway, by stracing getconf it turns out that the c library on fc12
> uses sysfs to determine the number of cpus, so I'm probably barking up
> the wrong tree. I read somewhere that some work to make sysfs container
> aware has already been done, so if any of the people who've done that 
> are listening, I'd appreciate a pointer or two. 
The sysfs per namespace is not yet merged. It was rejected because of 
some locking problem and because the sysfs itself does need some cleanup 
before adding the shadowing directories for the namespace, it's right 
now cleanup and pushed little by little. Be patient  :)

On the other side, the sysfs per namespace will only virtualize 
/sys/class/net so it will not give you the right informations for the cpu.

>   I'm assuming that its not going to be contentious to try and restrict
> the container's idea of the number of cpus on the system to only those
> cpus allocated to its cgroup. 

More information about the lxc-users mailing list