On Fri, 2013-11-01 at 17:56 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > On Fri, 2013-11-01 at 17:18 -0500, Serge Hallyn wrote: > > > Quoting Michael H. Warfield (m...@wittsend.com): > > > > On Thu, 2013-10-31 at 13:00 -0500, Serge Hallyn wrote: > > > > > Quoting Michael H. Warfield (m...@wittsend.com): > > > > > > I did incorporate your suggestion of using the hash of the rootfs > > > > > > path > > > > > > as the subdirectory under the hosts /dev/ for the container. I also > > > > > > > > > > (Printed this out to look it over, just putting all my comments > > > > > together > > > > > here) : > > > > > > > > > > 1. I think if /dev is not devtmpfs, we should just bail on this. > > > > > > > > > > 2. You say in comments that you're using the cgroup name, but it seems > > > > > you're actually just using the container name? > > > > > > > > > > 3. The cgroup name used to be unique, but now each mounted cgroupfs > > > > > can actually have a different name for the same container (if some > > > > > of them didn't get cleaned out well). > > > > > > > > Maybe I misunderstood something here but I thought you told me at > > > > > You did (or I wasn't clear :). The container names need to be unique > > > within > > > a given lxcpath. So you can > > > > > > lxc-create -t fedora -n Fedora19 > > > lxc-create -t fedora -n Fedora19 -P /opt/lxc1 > > > for i in `seq 2 201; do > > > lxc-create -t fedora -n Fedora19 -P /opt/lxc$i > > > done > > > > > and start them all by passing -P <lxcpath> to lxc-start. > > > > Yeah, that worked. Creates some, errr, cough, interesting > > ambiguities... > > > > [root@hydra ~]# lxc-ls > > Alcove Audience CentOS6 Faces Oracle Suse Y2 > > Alpine BusyBox Chaos Fedora19 Platform Ubuntu Yelm > > Anteroom CentOS5 Debian Fourier Plover Vault > > [root@hydra ~]# lxc-ls --active > > Alcove Audience Faces Fedora19-1 Oracle Plover Vault Yelm > > Anteroom Chaos Fedora19 Fourier Platform Suse Y2 > > [root@hydra ~]# > > > > So, Fedora19-1 shows up in "lxc-ls --active" but not in plain "lxc-ls". > > So it's an active container but not a container??? Interesting...
> That should definately not be happening. The lxcpath is encoded > in the abstract unix socket for controlling the container. So > I'm guessing lxc-ls --active is looking at cgroups and doing the > wrong thing there. Bugger. Yeah, but, if that's the case, shouldn't lxc-ls be showing both the containers? If "lxc-ls --active" is doing the "wrong" thing, what is the right thing? If I do a container ls, I would like to know all the containers that are on the system (which may not be possible without knowing all the possible lxcpath values, I admit). Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel