Quoting William Dauchy (wdau...@gmail.com): > Hello, > > I tested lxc0.8 rc1 and saw that cgroups are now created in > /cgroup/lxc/, so lxc-create will create the cgroups in this directory > as a cgroups hierarchy. > It makes the thing unusable when using cgroups capabilities that does > not support hierarchies. I'm thinking about CONFIG_NETPRIO_CGROUP in > the last 3.3 kernel which only support cgroups created in /cgroup > directory. > Is it a known issue? or is it planned to configure the directory?
The issue of what to do with control groups which do not support hierarchies has been discussed on lkml recently. I thought (though maybe I'm wrong) the decision was that such a subsystem would have its cgroups available at leaf nodes, i.e. it's /xyz cgroup, if composed with a devices cgroup which has /abc/xyz, would be visible at /abc/xyz. IIRC one of the primary drivers of the need for this was systemd support. Putting lxc cgroups under lxc/ is the right thing to do to cooperate with other programs using cgroups, like libvirt. I don't think we should punt on that. Rather, I personally think it's reasonable to say that if you are using a cgroup which has max depth 1, you should mount it separately. If you then want to use it with lxc, perhaps we should, for now have a hack which specifis which cgroups do not support hierarchies, and handle them specially? -serge ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
