Quoting John (l...@jelmail.com): > On 07/12/12 13:50, Serge Hallyn wrote: > > 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... > > I always treated /var/lib/lxc as "internal". From the early days, > /etc/lxc was suggested as a configuration directory and where the > original configuration would lie. Using lxc-create copied that config > into /var/lxc. This, in my mind, meant that I shouldn't mess with the > config inside /var/lib/lxc but should instead modify /etc/lxc and then > do a destroy/create. I may have been living on a mis-premise all this > time but that's how I've been using it.
No actually I like that. I've not done it, but it seems sound. > >> 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)? > yes, that would work. Great - if someone gets to writing that patch before I do, +1. -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