Re: [libvirt] [RFC] [PATCH v2 1/6] add configure option --with-fuse for libvirt

于 2012年09月05日 20:42, Daniel P. Berrange 写道: > On Wed, Sep 05, 2012 at 05:41:40PM +0800, Gao feng wrote: >> Hi Daniel & Glauber >> >> 于 2012年07月31日 17:27, Daniel P. Berrange 写道: >>> Hi Gao, >>> >>> I'm wondering if you are planning to attend the Linux Plumbers Conference >>> in San Diego at the end of August ? Glauber is going to be giving a talk >>> on precisely the subject of virtualizing /proc in containers which is >>> exactly what your patch is looking at >>> >>> https://blueprints.launchpad.net/lpc/+spec/lpc2012-cont-proc >>> >>> I'll review your patches now, but I think I'd like to wait to hear what >>> Glauber talks about at LPC before we try to merge this support in libvirt, >>> so we have an broadly agreed long term strategy for /proc between all the >>> interested userspace & kernel guys. >> >> I did not attend the LPC,so can you tell me what's the situation of the >> /proc virtualization? >> >> I think maybe we should just apply this patchset first,and wait for somebody >> sending patches to implement /proc virtualization. > > So there were three main approaches discussed > > 1. FUSE based /proc + a real hidden /.proc. The FUSE /proc provides custom > handling of various files like meminfo, otherwise forwards I/O requests > through to the hidden /.proc files. This was the original proof of > concept. > > 2. One FUSE filesystem for all containers + a real /proc. Bind mount files > from the FUSE filesystem into the container's /proc. This is what Glauber > has done. > > 3. One FUSE filesystem per container + a real /proc. Bind mount files from > the FUSE filesystem into the container's /proc. This is what your patch > is doing > > Options 2 & 3 have a clear a win over option 1 in efficiency terms, since > they avoid doubling the I/O required for the majority of files. > > Glaubar thinks it is perferrable to have a single FUSE filesystem that > has one sub-directory for each container. Then bind mount the appropriate > sub dir into each container. > > I kinda like the way you have done things, having a private FUSE filesystem > per container, for security reasons. By having the FUSE backend be part of > the libvirt_lxc process we have strictly isolated each containers' environment. > > If we wanted a single shared FUSE for all containers, we'd need to have some > single shared daemon to maintain it. This could not be libvirtd itself, since > we need the containers & their filesystems to continue to work when libvirtd > itself is not running. We could introduce a separate libvirt_fused which > provided a shared filesystem, but this still has the downside that any > flaw in its impl could provide a way for one container to attack another > container Agree,if we choose the option 2,we have to organize the sub-directory for each container in fuse,it will make fuse filesystem complicated.