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 So in summary, I think your patches which add a private FUSE per container in libvirt_lxc appear to be the best option at this time. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|