This Time Self-Hosted
dark mode light mode Search

Some more notes about Linux Containers

I’ve been playing around more with Linux Containers after my post about init scripts and I start to think they are quite near being working for Gentoo. I hope once I come back from my vacations to get them in the tree together with Tiziano.

Right now the problems we have are:

  • the standard stage3 needs to be heavily tweaked or it’ll be a massacre when started;
  • if I do set ttys in the configuration, at start time it moves me to the real tty1, which causes a domino effect with X11 that is annoying, although not critical;
  • OpenRC needs to be tweaked to add support for Linux-Containers; there are quite a few things that could be eased up by having a working OpenRC that ignores some init scripts when running in containers; the code seems to be in src/librc/librc.c (look for openvz) and should be easy to check whether we’re running on containers, by checking the running cgroup (/proc/self/cgroup);
  • the current ebuild in Tiziano’s overlay creates a /var/lib/lib directory and installs the lxc- binaries in /usr/bin, both of which shouldn’t happen in Gentoo once installed;
  • running rc shutdown inside the container will stop all the services properly, but will not kill init and thus not kill the vserver, I’m not sure why; running kill 1 also seems not to work, I have yet to check whether sending the kill signal from outside will properly shut down the rc inside, if yes, then it’ll be a good way to shut down the container.

Once I’ll be back and I’ll be working on the init scripts, they’ll be in a separate package, kinda like mysql’s, since what I have for now is slightly more complex, will add a few more standard locations (for instance they’ll use a /var/log/lxc directory that is not part of the standard install of lxc) and will require a couple of packages that are not part of lxc.

Comments 5
  1. I think I had better luck than you with containers so far. (Almost) everything seems to work fine. I don’t have the issue with the ttys and the vserver shuts down without any issues when I do an init 0 inside it (it even kills the init process inside the container). The guest system is just an ordinary stage3 installation with baselayout 2 having the following init scripts disabled: udev, keymaps and consolefont. I tty solved the tty problem as follows: I enabled the options CONFIG_CGROUP_DEVICE and CONFIG_DEVPTS_MULTIPLE_INSTANCES in the kernel and then I used the following options in the config file for the vserver:<typo:code>lxc.tty = 12lxc.pts = 1024lxc.cgroup.devices.deny = a# /dev/null and zerolxc.cgroup.devices.allow = c 1:3 rwmlxc.cgroup.devices.allow = c 1:5 rwm# consoleslxc.cgroup.devices.allow = c 4:1 rwmlxc.cgroup.devices.allow = c 4:2 rwmlxc.cgroup.devices.allow = c 4:3 rwm…(all device minor numbers from 1 thru 12)…lxc.cgroup.devices.allow = c 4:12 rwmlxc.cgroup.devices.allow = c 5:0 rwmlxc.cgroup.devices.allow = c 5:1 rwmlxc.cgroup.devices.allow = c 5:2 rwmlxc.cgroup.devices.allow = c 136:* rwm# /dev/{,u}randomlxc.cgroup.devices.allow = c 1:9 rwmlxc.cgroup.devices.allow = c 1:8 rwm# rtclxc.cgroup.devices.allow = c 254:0 rwm</typo:code>

  2. The numbering in my comment above was added automatically (due to Textile). In place of numbers I actually had comments (ie lines starting with a sharp).

  3. I have not yet played around with LXC, it’s rather new stuff, but I have some systems happily running the similar[*] linux-vserver (http://www.linux-vserver.org/) and trying to get it back to a useful state in Gentoo/HPPA (you’ll find me in bugzilla ;).[*] I still don’t know what the differences are between linux-vserver and lxc, I’m using the former since that’s what I’m used to and also because the latter has been introduced some years later 🙂

  4. I just commented on the 6 month old article with the (ok, A) way for the host to trigger the container to shut itself down gracefully, so a host init script can shut down all containers before it shuts itself down. The lxc-users mail list came up with it. They also came up with an answer for this question.For the container to shut all the way down and actually go away (lxc-stop), (also, for the container to perform a reboot, lxc-stop;lxc-start) you make a process on the host watch the containers utmp file for changes with inotifywait, when the file changes at all, wake up and run runlevel on it and get the containers desired new runlevel. If it starts with N, ignore it, if it’s not N** , then consider the last character, if it’s 0 the container wants to shut down, 6 the container wants to reboot, next watch the containers tasklist in cgroup mount and wait for it to shrink to 1, then perform lxc-stop, or lxc-stop;lxc-start. Voila, virtual motherboard BIOS!If you use the sigpwr -> init trick to trigger the shutdown, and then just wait with lxc-wait for the container to be stopped, the monitor script described above will end up doing the nice waiting for the processes to all go away and the actual lxc-stop, so, you have a nice safe shut-down-all-containers host init script so the host can shut down safely without any special admin action.openSUSE scripts to do all that.http://nj10.aljex.com/lxclink will go away at some point.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.