Re: [libvirt] Intend to add fuse filesystem support for libvirt lxc

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.

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

- 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