it would be cool to be able to clone an lxc container onto aufs for test runs - ephemeral containers

I discussed adding this to lxc-start with Serge on IRC, but dimishing returns - the shell script is possibly better/simpler : I'll leave this as a proof of concept for others to migrate into C if desired.

Updated the attachment with some docs.

Thanks. It's an interesting and useful idea.

Note that, in oneiric, you can do something similar using LVM snapshots.
Once you have an LVM container (automation of which is trivial but not
yet automated by a tool in the package :) you can

 lxc-clone -s -o basecontainer -n tmpcontainer
 lxc-start -n tmpcontainer

which takes about 3 seconds altogether. When done, destroy
tmpcontainer.

So one alternative workflow for this would be to extend lxc-clone
to support aufs as an alternative to lvm, using your model. So then
start an aufs container would be a two-step process, i.e.

 lxc-clone --aufs -o basecontainer -n tmpcontainer
 lxc-start -n tmpcontainer -d
 lxc-destroy -n tmpcontainer

It's an extra step at startup, but OTOH it allows tmpcontainer to
more easily persist, sort of like schroot sessions. You could then
also script the steps into a single 'lxc-aufsstart'.

Does that sound sufficiently useful to you, or do you see advantages
to extending lxc-start to have a --aufs option to emulate your script?

On Sat, Jul 9, 2011 at 9:16 AM, Serge Hallyn <email address hidden> wrote:
> Thanks.  It's an interesting and useful idea.
>
> Note that, in oneiric, you can do something similar using LVM snapshots.
> Once you have an LVM container (automation of which is trivial but not
> yet automated by a tool in the package :) you can
>        lxc-clone -s -o basecontainer -n tmpcontainer
>        lxc-start -n tmpcontainer
>
> which takes about 3 seconds altogether.  When done, destroy
> tmpcontainer.

Yes, one of the key differences though is that writes to aufs never
hit disk; they don't need to block on fsync and so forth: we're
running postgresql, so this can make quite a difference to IO
contention.

> So one alternative workflow for this would be to extend lxc-clone
> to support aufs as an alternative to lvm, using your model.  So then
> start an aufs container would be a two-step process, i.e.
>
>        lxc-clone --aufs -o basecontainer -n tmpcontainer
>        lxc-start -n tmpcontainer -d
>        lxc-destroy -n tmpcontainer
>
> It's an extra step at startup, but OTOH it allows tmpcontainer to
> more easily persist, sort of like schroot sessions.  You could then
> also script the steps into a single  'lxc-aufsstart'.
>
> Does that sound sufficiently useful to you, or do you see advantages
> to extending lxc-start to have a --aufs option to emulate your script?

I'm completely agnostic about how and where it lives ;) We'd like the
functionality though.

-Rob

Note to whomever merges / rewrites to C /whatever - this needs SIGTERM/SIGINT/SIGQUIT handling to unmount the bind mounts, tempfs mount, aufs mount and rm -rf the temp directories.

updated script that handles slower startup and doesn't leak LXC_DIRs

This bug was fixed in the package lxc - 0.7.4.2-3ubuntu6

---------------
lxc (0.7.4.2-3ubuntu6) oneiric; urgency=low

  * Add lxc-start-ephemeral by Robert Collins (LP: #807351)
  * Add a --quit-on-stop arg to lxc-monitor for use by lxc-start-ephemeral.
  * Modify lxcguest.conf to clear out /var/run (LP: #819621)
  * Fix a bug in lxc-ps when cgroup-bin is not mounted.
  * Modify lxc-ps to accept '-n name' and support '--' to separate options
    for ps. (LP: #820720)
 -- Serge Hallyn <email address hidden> Wed, 03 Aug 2011 19:48:11 -0500