[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]