On Mon, 2013-06-10 at 08:48 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (m...@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 | m...@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!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
