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. [...] >> 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. > -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
