[Lxc-users] restricting container visible cpus

[atp]

Daniel,

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

  Ok, fair enough. I'll proceed with the setup as it stands then. My
initial target will be to fix meminfo, and mask /proc/cpuinfo
and /proc/stat. 
  
  You need something that can bridge the gap, and represent a masked
view of the host /proc into the container, using context from the
control group of that container. That implies that there is something
running in the host thats mounted in the container /proc. 

  I understand your points below about not changing /proc in the kernel,
but if lxc is to be a replacement for openvz, then the isolation of the
container needs to be improved. There's nothing to stop a container
admin mounting the hosts /proc filesystem, unless there's something
in the kernel to steer them in the right direction. I view this not as 
virtualisation, but more as isolation, which is in the remit of a
container. 

  For that reason, I think that a kernel module makes the most sense in
the long run, if the core kernel can't be modified. For now, I'll work
on the procfs fuse module. 

  I'll post up my changes in a day or so. 

  Thanks 
    
  Andy

> 
Andrew Phillips
Head of Systems

www.lmax.com 

Office: +44 203 1922509
Mobile: +44 (0)7595 242 900

LMAX | Level 2, Yellow Building | 1 Nicholas Road | London | W11 4AN




The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company.