Hi Daniel 于 2012年06月29日 17:50, Daniel P. Berrange 写道:

On Fri, Jun 29, 2012 at 11:05:33AM +0800, Gao feng wrote:

...

Hi Everyone,

Now I'm working on making the container's system info(such as /proc/meminfo,cpuinfo..) isolate from the host.

I made a patch which implement showing the /proc/meminfo base on container's memcg, and sent it to the community.(http://marc.info/?l=linux-mm&m=133826035821338&w=2)

but I found it's difficult to be accepted, because this way is ugly, and somebody gave me some suggestions.

the first way is making another kernel file(just like memory.limit_in_bytes),and mount it to the container. I don't like this way,because there will be many redundance information between this new kernel file and the existing kernel file,some files such as memory.stat already contains memcg information.

the other way is adding fuse filesystem support for libvirt lxc. with this way, we can simply collect information from cgroup in fuse_operations.read function, and mount this file to the container. we can impletment isolate meminfo in userspace without changing kernel codes.

I have impletment fuse support for libvrit now, and ready to impletement the meminfo isolated.

I want to know if you have any comment or another ideas?

Having read that long thread you quote above, I tend to agree that creating a FUSE filesystem is probably the best option we have for dealing with /proc in the short term. I'd expect it to be provided either in the libvirt_lxc controller process that is forked per container, or even perhaps in a new process libvirt_lxc_fuse forked per container.

Thanks for your reply. Now I implement it as a fork of libvirt_lxc.

I can see two ways todo it

- Provide a FUSE filesystem that just contains the couple of files we need, and then bind them over the top of the files in /proc

I select this way now,because proc filesystem provide some task's information, the way you mention below will cause those information unavailable.

- Provide a FUSE filesystem that does a union-fs like layering on top of an existing /proc mount, avoiding the need for bind mounts

Daniel