Re: [libvirt] [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace

On 08/26/2013 02:16 AM, James Bottomley wrote: > On Sun, 2013-08-25 at 19:37 +0200, Kay Sievers wrote: >> On Sun, Aug 25, 2013 at 7:16 PM, James Bottomley >> <jbottomley(a)parallels.com&gt; wrote: >>> On Wed, 2013-08-21 at 11:51 +0200, Kay Sievers wrote: >>>> On Wed, Aug 21, 2013 at 9:22 AM, Gao feng <gaofeng(a)cn.fujitsu.com&gt; wrote: >>>>> On 08/21/2013 03:06 PM, Eric W. Biederman wrote: >>>> >>>>>> I suspect libvirt should simply not share /run or any other normally >>>>>> writable directory with the host. Sharing /run /var/run or even /tmp >>>>>> seems extremely dubious if you want some kind of containment, and >>>>>> without strange things spilling through. >>>> >>>> Right, /run or /var cannot be shared. It's not only about sockets, >>>> many other things will also go really wrong that way. >>> >>> This is very narrow thinking about what a container might be and will >>> cause trouble as people start to create novel uses for containers in the >>> cloud if you try to impose this on our current infrastructure. >>> >>> One of the cgroup only container uses we see at Parallels (so no >>> separate filesystem and no net namespaces) is pure apache load balancer >>> type shared hosting. In this scenario, base apache is effectively >>> brought up in the host environment, but then spawned instances are >>> resource limited using cgroups according to what the customer has paid. >>> Obviously all apache instances are sharing /var and /run from the host >>> (mostly for logging and pid storage and static pages). The reason some >>> hosters do this is that it allows much higher density simple web serving >>> (either static pages from quota limited chroots or dynamic pages limited >>> by database space constraints) because each "instance" shares so much >>> from the host. The service is obviously much more basic than giving >>> each customer a container running apache, but it's much easier for the >>> hoster to administer and it serves the customer just as well for a large >>> cross section of use cases and for those it doesn't serve, the hoster >>> usually has separate container hosting (for a higher price, of course). >> >> The "container" as we talk about has it's own init, and no, it cannot >> share /var or /run. > > This is what we would call an IaaS container: bringing up init and > effectively a new OS inside a container is the closest containers come > to being like hypervisors. It's the most common use case of Parallels > containers in the field, so I'm certainly not telling you it's a bad > idea. > >> The stuff you talk about has nothing to do with that, it's not >> different from all services or a multi-instantiated service on the >> host sharing the same /run and /var. > > I gave you one example: a really simplistic one. A more sophisticated > example is a PaaS or SaaS container where you bring the OS up in the > host but spawn a particular application into its own container (this is > essentially similar to what Docker does). Often in this case, you do > add separate mount and network namespaces to make the application > isolated and migrateable with its own IP address. The reason you share > init and most of the OS from the host is for elasticity and density, > which are fast becoming a holy grail type quest of cloud orchestration > systems: if you don't have to bring up the OS from init and you can just > start the application from a C/R image (orders of magnitude smaller than > a full system image) and slap on the necessary namespaces as you clone > it, you have something that comes online in miliseconds which is a feat > no hypervisor based virtualisation can match. > > I'm not saying don't pursue the IaaS case, it's definitely useful ... > I'm just saying it would be a serious mistake to think that's the only > use case for containers and we certainly shouldn't adjust Linux to serve > only that use case. > The feature you said above VS contianer-reboot-host bug, I prefer to fix the bug.

and this feature can be achieved even container unshares /run directory with host by default, for libvirt, user can set the container configuration to make the container shares the /run directory with host. I would like to say, the reboot from container bug is more urgent and need to be fixed.