[Lxc-users] Sharing container rootfs

[Michael H. Warfield]

On Mon, 2013-06-10 at 08:48 -0500, Serge Hallyn wrote: 
> Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > On Fri, 2013-06-07 at 08:45 +0000, Purcareata Bogdan-B43198 wrote: 
> ...
> > I use to do something similar a lot under the old linux-vservers project
> > (now defunct for several years - mailing list is now dead).  They used a
> > COW (Copy On Write) system to maintain a common READ ONLY root system
> > and per-vserver modified layers of changes each server made while
> > running.  It was quite a nice feature.
> > 
> > In theory, this is the idea of using a rootfs image with a unionfs rw
> > layer on top of that for the running container.  That way, you only have
> > one copy of a binary on disk and only one copy of the shared executable
> > code in memory, yet the containers all have unique modifiable root file
> > systems.  So it works in principle.  Implementation can be another
> > matter.
> > 
> > I think I recall having done this with OpenVZ (after linux-vserver
> > failed in ongoing IPv6 support forced me over to OpenVZ) but that also
> > would have been a long time ago.  More recently (but still more than a
> > year ago) I tried the same technique using unionfs with LXC which failed
> > horribly.  Functionally, it should appear to be similar to a bind mount
> > but bind mounts are currently problematical with some of the hacks we've
> > had to implement to work around systemd conventions.  I haven't tried it
> > in well over a year.  I suppose I should try that again.  Maybe it would
> > work now...

> This is (IIUC) what lxc-start-ephemeral is meant to do - and also what
> 'lxc-clone -B overlayfs -o containerbase -n containerA' is meant for, where
> containerbase is a canonical, directory-backed container which all other
> containers are based upon, and containerA becomes a usable container
> with an overlayfs or aufs write layer mounted over containerbase's
> readonly rootfs.

Oh you UC, all right.  Now that's perfect.  Maybe I missunderstood what
"ephemeral" did.  I assumed that, after the container was stopped, all
the "ephemeral" data would be lost (IOW a throw-away instantiation).  If
that's persistent across starts, that would be what I was doing.  I
haven't played with lxc-start-ephemeral or lxc-clone as yet.  Sounds
like I need to and save my self some grief.  That may even be the real
answer to the OP's quest.  Really sounds like lxc-clone with overlayfs
is a match for what I had been doing.

> It's how both docker and https://github.com/hallyn/lxc-snap provide
> incremental container image development.

Nice.

> -serge

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20130610/b1a33359/attachment.pgp>