Quoting John (l...@jelmail.com):
> On 07/12/12 00:48, Serge Hallyn wrote:
> >Quoting John (l...@jelmail.com):
> >>On 06/12/12 20:06, Dan Kegel wrote:
> >>>On Thu, Dec 6, 2012 at 12:00 PM, John <l...@jelmail.com> wrote:
> >>>>While on the subject, any reason for lxc-destroy now being destructive?
> >>>Wait, isn't that the point? It's in the name and all.
> >>>
> >>>When was it ever nondestructive?
> >>>
> >>It only destroyed the configuration in /var/lib and never deleted the
> >>root filesystem until very recently (0.8.0, I guess).
> >Was your rootfs a symbolic link by chance? I'm guessing commit
> >55116c42e767ce795f796fc51cd2ef7d76cf18af is what you're seeing. Before
> >that it did remove the rootfs, but if your rootfs was a symlink it
> >happened to not do it. That wasn't by intent.
> >
> >Perhaps lxc-destroy should take a flag to not delete the rootfs? Not
> >sure...
> >
>
> Ah, I can now see what is wrong. It isn't down to symlinks but
> beacuase my rootfs isn't under /var/lib/lxc.
>
> Looking at that commit, I can see that the remove (on line 126)
> deletes "$lxc_path/$lxc_name" but does not explictly remove
> "$rootdev". The new code added at line 122 does indeed remove
> $rootdev.
>
> In my case I have my container rootfs in a directory called
> "/srv/test.i686" (i.e not underneath $lxc_path - /var/lib/lxc). I
> guess the design assumes that a template is used to create a
> container and that it would put the rootfs beneath /var/lib/test.
>
> So the commit fixes an anomaly but leaves me unsure of a couple of things:
>
> 1. what is the correct way to update a container config without
> removing the rootfs. I have always used destroy/create to do this
> but that, clearly, won't work if the destroy phase removes the
> rootfs. I like being able to separately manage the rootfs from its
> configuration.
This I don't really understand - I've always done it by hand. What
exactly is made easier by doing destroy/create? Maybe we can reproduce
that with an lxc-update or something... Especially if we can then
have lxc-update expand variables and take a list of containers to
update to batch the operations. Though still right now I would just
default to a bash loop calling sed...
> 2. is it wrong to have the rootfs outside of the /var/lib/lxc ? I
Not if you're doing it right :) That's in fact why the --dir option
was added. But that's exactly why the lxc-destroy behavior should
be the same with the rootfs in our out of /var/lib/lxc/$container.
> have a small /var but use a large dedicated partition for my root
> filesystem directories. I suspect I need to look at using
> per-container lvm volumes, something that makes sense but I haven't
> delved into yet.
If it's working for you and you don't need separate volumes for fast
snapshotted clones, I wouldn't change it. We need to make sure to
support your use case.
> I would value having options to preserve the rootfs when doing
> lxc-destroy and for lxc-create to use an existing rootfs (i.e.
> instead of a template).
Ok, I don't *really* want to make lxc-destroy not delete the rootfs
just if it is outside of /var/lib/lxc/$container... On the one hand
I can see people could do that specifically in the hopes of making
it outlive the container. On the other hand I could see people doing
it only because they are short on disk space ending up running out of
disk space because they lost track of where the undeleted rootfs's
were.
Maybe
lxc-destroy -k -n p1
for "--keep" (don't delete the rootfs)?
-serge
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
