[lxc-devel] lxc0.8 and hierarchies
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? Regards, -- William -- 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
Re: [lxc-devel] lxc0.8 and hierarchies
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
Re: [lxc-devel] lxc0.8 and hierarchies
Hi Serge, Thanks for your quick reply. On Wed, May 2, 2012 at 4:14 PM, Serge Hallyn wrote: > 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? I guess you were talking about this thread https://lkml.org/lkml/2012/2/21/379 Thanks for the explanation. It's quite clear and could be useful for users asking them self the same question. -- William -- 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
Re: [lxc-devel] lxc0.8 and hierarchies
On 02/05/12 10:14, Serge Hallyn wrote: > Quoting William Dauchy (wdauchy-re5jqeeqqe8avxtiumw...@public.gmane.org): >> 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 Right now lxc is hard-coded to not create a 'lxc/' directory in a cgroup hierarchy if it contains the (deprecated) 'ns' subsystem. So maybe the code should also check for the 'netprio' subsystem in the same way? I'm not sure if this is relevant to your problem, but last month I sent a patchset that, among other things, fixes lxc to properly handle cgroup hierarchies that do not contain any subsystems (like systemd): http://sourceforge.net/mailarchive/forum.php?thread_name=4F6ADBDA.9040400%40free.fr&forum_name=lxc-devel David -- 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
[lxc-devel] lxc0.8rc2
Hello, I saw that lxc-0.8.0-rc2 has been tagged 6 weeks ago (http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=summary) I was wondering why there was no package available in http://lxc.sourceforge.net/download/lxc/ (since rc1 is present) Regards, -- William -- 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
Re: [lxc-devel] [PATCHv3 05/14] cgroup: additional fix for deprecated ns subsystem
On 21/03/12 19:28, Ward, David - 0663 - MITLL wrote:
When a hierarchy contains the 'ns' subsystem, do not append '/lxc'
to the parent cgroup. Update surrounding comments for consistency.
Signed-off-by: David Ward
This patch is actually unnecessary. The existing code already handled
the 'ns' subsystem; the sequence of function calls is just a bit
confusing. All other patches in this set are still valid.
David
---
src/lxc/cgroup.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c
index 9af199d..e5145f9 100644
--- a/src/lxc/cgroup.c
+++ b/src/lxc/cgroup.c
@@ -305,9 +305,9 @@ static int lxc_one_cgroup_create(const char *name,
char initcgroup[MAXPATHLEN];
int flags, ret;
- /* cgparent is the parent dir,
/sys/fs/cgroup///lxc */
+ /* cgparent is the parent dir, e.g.,
/sys/fs/cgroup///lxc */
/* (remember get_init_cgroup() returns a path starting with '/') */
- /* cgname is the full name,
/sys/fs/cgroup///lxc/name */
+ /* cgname is the full name, e.g.,
/sys/fs/cgroup///lxc/name */
ret = snprintf(cginit, MAXPATHLEN, "%s%s", mntent->mnt_dir,
get_init_cgroup(NULL, mntent, initcgroup));
if (ret< 0 || ret>= MAXPATHLEN) {
@@ -315,7 +315,10 @@ static int lxc_one_cgroup_create(const char *name,
return -1;
}
- ret = snprintf(cgparent, MAXPATHLEN, "%s/lxc", cginit);
+ flags = get_cgroup_flags(mntent);
+
+ ret = snprintf(cgparent, MAXPATHLEN, "%s%s", cginit,
+ (flags& CGROUP_NS_CGROUP) ? "" : "/lxc");
if (ret< 0 || ret>= MAXPATHLEN) {
SYSERROR("Failed creating pathname for cgroup parent (%d)\n",
ret);
return -1;
@@ -326,8 +329,6 @@ static int lxc_one_cgroup_create(const char *name,
return -1;
}
- flags = get_cgroup_flags(mntent);
-
/* Do we have the deprecated ns_cgroup subsystem? */
if (flags& CGROUP_NS_CGROUP) {
WARN("using deprecated ns_cgroup");
@@ -356,7 +357,7 @@ static int lxc_one_cgroup_create(const char *name,
return -1;
}
- /* if /sys/fs/cgroup///lxc does not exist, create
it */
+ /* if cgparent does not exist, create it */
if (access(cgparent, F_OK)&& mkdir(cgparent, 0755)) {
SYSERROR("failed to create '%s' directory", cgparent);
return -1;
smime.p7s
Description: S/MIME Cryptographic Signature
--
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
Re: [lxc-devel] [PATCHv3 05/14] cgroup: additional fix for deprecated ns subsystem
On 05/02/2012 06:43 PM, Ward, David - 0663 - MITLL wrote: > On 21/03/12 19:28, Ward, David - 0663 - MITLL wrote: >> When a hierarchy contains the 'ns' subsystem, do not append '/lxc' >> to the parent cgroup. Update surrounding comments for consistency. >> >> Signed-off-by: David Ward > > This patch is actually unnecessary. The existing code already handled > the 'ns' subsystem; the sequence of function calls is just a bit > confusing. All other patches in this set are still valid. Ok. Thanks. -- Daniel -- 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
[lxc-devel] [PATCH 1/1] put quotes around $line to avoid expansion of its contents.
Otherwise things like '*:*' in config can get expanded if there is a
matching filename in cwd.
Signed-off-by: Serge Hallyn
---
src/lxc/lxc-clone.in |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lxc/lxc-clone.in b/src/lxc/lxc-clone.in
index 28c47e8..c9a8691 100644
--- a/src/lxc/lxc-clone.in
+++ b/src/lxc/lxc-clone.in
@@ -275,7 +275,7 @@ while read line; do
if [ "${line:0:18}" = "lxc.network.hwaddr" ]; then
echo "lxc.network.hwaddr= 00:16:3e:$(openssl rand -hex 3| sed
's/\(..\)/\1:/g; s/.$//')"
else
- echo $line
+ echo "$line"
fi
done
) < ${c}.old > ${c}
--
1.7.9.5
--
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
