Quoting Michael H. Warfield (m...@wittsend.com): > 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
BY default it is, but there is a --keep-data option which stops that from happening. -serge ------------------------------------------------------------------------------ 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
