Re: [Lxc-users] [PATCH 2/2] cgroups: support cgroups mounted in multiple places
On Sun, 2011-06-26 at 18:49 -0500, Serge E. Hallyn wrote:
Quoting Michael H. Warfield (m...@wittsend.com):
On Sun, 2011-06-26 at 14:00 -0500, Serge E. Hallyn wrote:
Quoting Michael H. Warfield (m...@wittsend.com):
Thanks, Michael, good catch.
Now wait a minute. Is that a typo here:
No it's not, but:
char *s = index(retbuf, '.');
If you're doing, in effect, a dirname here should that be this:
char *s = index(retbuf, '/');
IAC... That *s = '\0'; should include a NULL check.
Adding the NULL check and lxc-info works.
Looks like that subsystem name in the call to that routine is not what
Serge thought it was. I threw a print above the snprintf about just
for
giggles to print out the subsystem name being passed to it and this is
what I got back...
[mhw@forest SPECS]$ sudo lxc-info -n Alcove
subsystem name: freezer
'Alcove' is RUNNING
No wonder s was null. No dot and no /.
I applied this patch and it got lxc-info working. But it was a quick
hack just to address the NULL pointer. Is it the correct fix?
No, it's not.
For the calls to this function that come from cgroup.c itself, '.' is the
right thing. The problem is that lxc_cgroup_set() and lxc_cgroup_get()
pass in things like 'devices.allow'. I was going to make the index
conditional, but all the callers of this function pass in either a
filename
(with a '.' in it) or NULL.
I failed to notice these:
src/lxc/freezer.c: ret = lxc_cgroup_path_get(nsgroup, freezer,
name);
src/lxc/state.c:err = lxc_cgroup_path_get(nsgroup, freezer,
name);
:)
These are what you are running into.
So the thing to do is leave it searching for index(s, '.') but do nothing
if s is NULL.
And that's what I believe results with my little hack. Only truncate if
Oops, sorry, I didn't look closely enough and assumed your patch was
switching to checking for '/'.
there was a hit and s was non-null. I see now from your comments that
the check on '.' was correct. I was uncertain about the inputs and
outputs in this routine. Checking for the NILL condition may not be
the solution, in this case, but it is still a best common practice to
check pointers like that. Never can tell what may crop up in the
future.
Really it would be cleaner to have lxc_cgroup_{sg}et() do the index, so
that lxc_cgorup_path_get() always gets a subsystem or NULL. I'm not doing
that patch right now, though, trivial as it ought to be.
I hear you.
So
Acked-by: Serge Hallyn serge.hal...@ubuntu.com
to your patch to fix my bug, and let's leave it at that for now until it
gets more testing?
Cool. I now have it running in 3 environments. Two are Fedora 12 (I
know, I know, it's on my todo list) i686 systems with single cgroup
mounts while the other is my Fedora 15 x86_64 platform. All are running
quite smoothly and lxc-info is working.
Daniel: Did you pick up my little patch from a couple of messages back?
That message did not including the -devel list. Should I also send it
there?
Thanks again for testing and looking into it!
-serge
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
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Use XID tagging with LXC
Quoting Julien VAUBOURG (jul...@vaubourg.com): Hi all, I would like to handle disk quotas of my containers, but in avoiding to use partitions. With linux-vserver, this is possible with the xid tagging and the vdlimit command[0]. Would you know if LXC can use xid in the same way ? Thanks in advance. Cheers, Ju. [0] http://linux-vserver.org/Disk_Limits_and_Quota The vserver xid tagging is not upstream. You can port that support and either patch your own kernel or try to push it upstream. As an alternative, see 'man xfs_quota' for directory tree quotas, which may give you what you need. -serge -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] Host resource visibility inside container; network interfaces inside containers
Dear List, I am in the middle of looks to be a very successful migration from a Xen based platform to LXC. I am still getting used to the LXC approach, though, and I was wondering if anybody could help me with two questions that have cropped up: - I don't quite seem to understand how cgroup would actually work in practice. Primarily, is it to be expected that the container sees all memory and CPU cores of the host, and is it possible to avoid this in any way, i.e. allocate 4 cores to a container and that is what you also see through top, /proc/cpuinfo et al? - Is it possible to use other network interfaces, in particular dummy and ipip inside a container? The closest I have got to a solution is allocating one 'phys' dummy interface per container, but that quickly gets clumsy. I also haven't figured out a way to use IP encapsulation inside the container - is that possible? Thanks in advance for your kind assistance. Best regards Jan -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] read only rootfs
On Mon, 2011-06-27 at 18:05 +0200, Samuel Maftoul wrote: I tried several ways to have the rootfs mounted RO. First I removed the lxc.rootfs from my config file and the tried: - lxc-start -n vm0 -o /tmp/lxc-vm0.log -l DEBUG -s lxc.mount.entry=/ /var/lib/lxc/vm0/rootfs none ro,bind 0 0 Then I tried: - echo / /var/lib/lxc/vm0/rootfs none ro,bind 0 0 /var/lib/lxc/vm0/fstab ; lxc-start -n vm0 -o /tmp/lxc-vm0.log -l DEBUG -s lxc.mount = /var/lib/lxc/vm0/fstab Finally I tried to boot with lxc.rootfs pointing to the same content, but on it's block device, mounted read-only The system starts, I have a console, but in the logs I get: lxc_conf - ignoring mount point '/var/lib/lxc/vm0/rootfs/lib' lxc_conf - ignoring mount point '/var/lib/lxc/vm0/rootfs/usr/lib' and of course, If I ls these directories, I have nothing inside. Bind mounting the root fs is fine, but it will not bind mount file systems under this, so you will need to add these to your fstab too. It looks like you have /lib and /usr/lib mounted on separate file systems and need to bind mount these too? Justin -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] read only rootfs
On Mon, 2011-06-27 at 17:20 +0100, Justin Cormack wrote: On Mon, 2011-06-27 at 18:05 +0200, Samuel Maftoul wrote: I tried several ways to have the rootfs mounted RO. First I removed the lxc.rootfs from my config file and the tried: - lxc-start -n vm0 -o /tmp/lxc-vm0.log -l DEBUG -s lxc.mount.entry=/ /var/lib/lxc/vm0/rootfs none ro,bind 0 0 Then I tried: - echo / /var/lib/lxc/vm0/rootfs none ro,bind 0 0 /var/lib/lxc/vm0/fstab ; lxc-start -n vm0 -o /tmp/lxc-vm0.log -l DEBUG -s lxc.mount = /var/lib/lxc/vm0/fstab Finally I tried to boot with lxc.rootfs pointing to the same content, but on it's block device, mounted read-only The system starts, I have a console, but in the logs I get: lxc_conf - ignoring mount point '/var/lib/lxc/vm0/rootfs/lib' lxc_conf - ignoring mount point '/var/lib/lxc/vm0/rootfs/usr/lib' and of course, If I ls these directories, I have nothing inside. Bind mounting the root fs is fine, but it will not bind mount file systems under this, so you will need to add these to your fstab too. It looks like you have /lib and /usr/lib mounted on separate file systems and need to bind mount these too? Bind mounts work but, iirc, there was (in the past) a problem that if the container did a remount, the remount would propagate to the parent device. That caused all sorts of headaches (and I know, I was suppose to retest that scenario ages ago and I haven't) like when a container remounted its rootfs ro during a shutdown it made partitions ro to the host. Very bad. This was also at the heart of the problem with shutdowns causing ptty failures for any subsequent connections an container starts (it made that fs ro). If you try to do this, you may have to prohibit mounts inside the containers to prohibit the remount problems. It would probably be a good idea to test it and see if the container can remount an ro mount point as rw and what the impact would be. Justin 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 -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] read only rootfs
On Mon, 2011-06-27 at 12:33 -0500, C Anthony Risinger wrote: On Mon, Jun 27, 2011 at 12:06 PM, Michael H. Warfield m...@wittsend.com wrote: On Mon, 2011-06-27 at 17:20 +0100, Justin Cormack wrote: On Mon, 2011-06-27 at 18:05 +0200, Samuel Maftoul wrote: I tried several ways to have the rootfs mounted RO. First I removed the lxc.rootfs from my config file and the tried: - lxc-start -n vm0 -o /tmp/lxc-vm0.log -l DEBUG -s lxc.mount.entry=/ /var/lib/lxc/vm0/rootfs none ro,bind 0 0 Then I tried: - echo / /var/lib/lxc/vm0/rootfs none ro,bind 0 0 /var/lib/lxc/vm0/fstab ; lxc-start -n vm0 -o /tmp/lxc-vm0.log -l DEBUG -s lxc.mount = /var/lib/lxc/vm0/fstab Finally I tried to boot with lxc.rootfs pointing to the same content, but on it's block device, mounted read-only The system starts, I have a console, but in the logs I get: lxc_conf - ignoring mount point '/var/lib/lxc/vm0/rootfs/lib' lxc_conf - ignoring mount point '/var/lib/lxc/vm0/rootfs/usr/lib' and of course, If I ls these directories, I have nothing inside. Bind mounting the root fs is fine, but it will not bind mount file systems under this, so you will need to add these to your fstab too. It looks like you have /lib and /usr/lib mounted on separate file systems and need to bind mount these too? Bind mounts work but, iirc, there was (in the past) a problem that if the container did a remount, the remount would propagate to the parent device. That caused all sorts of headaches (and I know, I was suppose to retest that scenario ages ago and I haven't) like when a container remounted its rootfs ro during a shutdown it made partitions ro to the host. Very bad. This was also at the heart of the problem with shutdowns causing ptty failures for any subsequent connections an container starts (it made that fs ro). If you try to do this, you may have to prohibit mounts inside the containers to prohibit the remount problems. It would probably be a good idea to test it and see if the container can remount an ro mount point as rw and what the impact would be. does this happen when the container rootfs is marked as a slave/private mount? slaves et al should not propagate changes to the master/host. That's exactly the thing that needs to be tested. I don't know at this point but I do know at one point it did not work properly and it did propagate. 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 -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
