Comment 6 for bug 807351
Revision history for this message
| Robert Collins (lifeless) wrote Re: [Bug 807351] Re: it would be cool to be able to clone an lxc container onto aufs for test runs - ephemeral containers | #6 |
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