[Lxc-users] debian and cgroup behaviour
Dear list. I've got the following error message with Debian squeeze (Kernel 2.6.32.5) and lxc 0.8: lxc-start: No such file or directory - failed to rename cgroup /sys/fs/cgroup//lxc/18381-/sys/fs/cgroup//lxc/vs-db lxc 0.7xx creates a folder under /sys/fs/cgroup/[init-process-id] and renames this folder to /sys/fs/cgroup/[container-name] lxc 0.8xx creates the same folder under /sys/fs/cgroup/*lxc/*[init-process-id] and renames it to /sys/fs/cgroup/*lxc*/[container-name] This result in lxc 0.8 won't start containers in squeeze and throw the rename error. lxc 0.7 can start the containers. And I don't know why. Anyone? (please don't advise to upgrade to wheezy, this is part of our upgrading tests :) ) -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Horrors using Debian Wheezy
I'm using your template on an Ubuntu 12.04 stock LXC install. I've run into a problem trying to use shared memory with Python's multiprocessing library. It relies on /dev/shm using tmpfs. I tried mounting it with an entry: lxc.mount.entry = tmpfs /dev/shm tmpfs defaults 0 0 and variations of the above without success. The included Ubuntu LXC template creates several tmpfs entries and I don't have this problem with it, so I think the issue is with the Debian guest. Do you have any idea how to fix this? My best guess is that it has something to do with the cgroup device restrictions. In the generated LXC configuration file you find several lxc.cgroup.devices.* entries. Remove these (make them comments) and restart your container. If this solves the problem you can probably copy the device entries from the Ubuntu configuration to the Debian configuration. Rob. http://freedomboxblog.nl -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] Working LXC templates? EUREAKA! I think I've got it!
On Sun, 2013-09-15 at 16:17 -0700, Tony Su wrote: Hello Michael, First a comment on problems with systemd you descrbe. I probably have run into many of the things you itemized, but since my time is usually focused on something I'm trying to use LXC and not LXC itself, I usually just drop any further attempts and move on to find a workaround(eg consoles) or use a different technology(x server issue). Regarding many of the issues you describe though, I wonder if they couldn't be addressed with more strict enforcement of using namespaces (and less often cgroups). I've read how namespaces are supposed to be an extremely powerful means of isolating processes and yet I don't see any obvious indications it's being done consistently... by either prepending to standard process or service names (if the goal is to easily identify the namespace) or using a random string (if the goal is better security so exploits can't anticipate commonly used namespaces). In fact, I think I see this namespace issue in various parts of the template you created. If I understand what is happening, there are numerous places where you create special nodes on the HostOS instead of (a) using the existing HostOS nodes but using namespaces to isolate Container processes (b) creating nodes entirely within the Container which would make the Container entirely portable but lose the benefit perhaps of the better ways nodes are created and mounted today(eg tmpfs in RAM). Diving more into your template code, I applaud your effort, it's significant and no minor effort. As of this moment, I've mainly been perusing what I might call HostOS Container Pre-Install, the part which precedes the actual installation and relies on components running in the HostOS only. This would be your script approx lines 0-410. 1. I like your method of identifying whether the OS is Fedora, and additionally whether is ARM or not. That was an effort working on my Raspberry Pi's. 2. It looks like you're configuring networking binding directly to eth0. I would recommend instead supporting the use of Linux Bridge devices, make declaration of a bridge device name as one of the early Global Parameters, then if exists to bind to that device by name. Your code to bind to the physical interface is less flexible but can be a default option if no bridge device is specified. Original code. I haven't really looked it it. As far as bridges and all go, much of that is in the greater LXC setup and the default settings in /etc/lxc/default.conf and outside of our control. 3. Interesting that you include an option for nm controlled yet at least initially I don't see where your code might rely on this setting. My code does not. In the back of my mind, the setting for NetworkMangler control is something that is used internally to the container and we're merely setting a default value. 4. mknod I'll have to take a closer look whether and why you appear to be setting up various consoles, some /dev/ nodes, an explicit console path, more. I've generally been under the impression that a full install automatically creates these. Peeking a bit ahead of where I've been reading your script, I notice your install method uses a pre-built squashfs image, perhaps these are a special requirement because your chosen squashfs image doesn't include these by default or requires those nodes to already exist? 5. Your use of yum will work in the RH family plus various others like openSUSE but I don't think it's native to distros like the Debian family. IMO there is no special benefit to using a package manager specific to the HostOS to download bootstrap images and packages, they aren't too relevant to the overall apps running in the HostOS and I think we should avoid installing non-native packages in any OS. For that reason, I've been looking at pycurl, curl and wget which are generic apps common to all distros which can accomplish the simple task of retrieving the bootstrap objects. (See the template I included as an attachment which uses pycurl and finds fedora repos rather than installing a pre-built img) Because yum (and rpm) are no ONLY and EVER executed in a chrooted environment, they are executing in a Fedora context and independent of the host environment. That's the whole point, it never execute the distro-dependent components in the host environment and only execute distro-agnostic (independent) components in the host environment. A small FYI - Although the Fedora template distributed with openSUSE which I've included as an attachment to this message does not work as is it might be useful to see a different way of obtaining and installing Fedora bootstrap packages so I've included it as an attachment to this message. I've said this before. Take it to the bank. The template that is distributed with OpenSuse is OUT OF DATE AND WILL NOT WORK! In fact, the entire LXC package that is distributed with OpenSuse is
Re: [Lxc-users] debian and cgroup behaviour
Quoting Andreas Laut (andreas.l...@spark5.de): Dear list. I've got the following error message with Debian squeeze (Kernel 2.6.32.5) and lxc 0.8: lxc-start: No such file or directory - failed to rename cgroup /sys/fs/cgroup//lxc/18381-/sys/fs/cgroup//lxc/vs-db lxc 0.7xx creates a folder under /sys/fs/cgroup/[init-process-id] and renames this folder to /sys/fs/cgroup/[container-name] lxc 0.8xx creates the same folder under /sys/fs/cgroup/*lxc/*[init-process-id] and renames it to /sys/fs/cgroup/*lxc*/[container-name] This result in lxc 0.8 won't start containers in squeeze and throw the rename error. lxc 0.7 can start the containers. And I don't know why. Anyone? For some time (between march and last week) the ns cgroup support was removed. It's back now, so maybe 1.0-alpha would work for you. -serge -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] LVM and XFS quota
Hi All I have a container running over a XFS logical volume, and would like to employ user-level disk quota. This doesn't work, but it seems like I need something like: mount -o remount,uquota /var/lib/lxc/vm0/rootfs/ The change seems to stick: /dev/mapper/lxc-vm0 on /var/lib/lxc/vm0/rootfs type xfs (rw,uquota) But, xfs_quota -xc 'report -h' /var/lib/lxc/vm0/rootfs/ yields xfs_quota: cannot setup path for mount /var/lib/lxc/vm0/rootfs/: No such device or address I am pretty sure that XFS needs to be *initially* mounted with the quota option --- but after rebooting I have lost the uquota. My guess is that I need to change the way lxc initially mounts the LV, but I've no idea how to go about that. Appreciate any insight anyone may have. Cheers Gary -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
