I’ve got a few further requests for Linux Containers support in Gentoo, one of which came from Alex, so I’ve decided to give it a try to update the current status of the stack, and give a decent description of what the remaining problems are.
First of all, the actual software: I’m still not fond of the way upstream is dealing with the lxc package itself; the build system is still trying to be smart and happening to be stupid, related to the LXC library. There are still very little failsafes, and there isn’t really enough space to manage LXC with the default tools as they are. While libvirt should support LXC just fine, I haven’t found the time to try it again and see if it works; I’m afraid it might only work if you use the forced setup that RedHat uses for LXC… but again I cannot say much until I find time to try it out and tweak it where needed.
A note, as I stated before a lot of the documentation and tutorials regarding libvirt only apply to RedHat or Fedora. I can’t blame them for that, they do the work, they do the walk, but often it means that we have to adapt them or at least find a way to provide them with the pieces they expect in the right place. It requires a lot of my time to do that.
I’ve finally added my “custom” init script to the ebuild, with version 0.7.2; it might change further with or without revision bump as I fix bugs reported; it should mostly auto-configure, the only requirement it has is to symlink to
lxc.container to start the container defined in
/etc/lxc/container.conf; it auto-detects the root path (so it won’t force you a particular filesystem layout), and works with both 32- and 64-bit containers transparently, so long there is a
/sbin/init command (which I could have to change for systemd-based distributions at some point). What I now reason it lacks is support for detecting the network interface it uses and require that started up; I can add that at some point, in the mean time use
/etc/conf.d/lxc.container and then add
For what concerns networking, last I checked with lxc 0.7.1 userspace, and kernel 2.6.34, the macvlan system still isolated the host from the guests, which might be what you want but it’s definitely not what I care for. I’m guessing this might actually be by design; at any rate, even though technically slower, I find myself quite comfortable with using a Linux-based bridge as main interface, and bridge together the Virtual Ethernet device of the guest with the physical interface(s) of the host. This also works fine with libvirt/KVM, so it’s not a bad decision in my opinion. I just added 0.7.2 but I can’t see how that makes a difference, as macvlan is handled in kernel.
Thankfully, doing so with Gentoo’s networking system (which Roy wanted to deprecate, tsk!) is piece of cake: open
config_br0, then add
ln -s net.lo /etc/init.d/net.br0, and use that for bringing the network up. Then on the LXC configuration side you got
lxc.network.type = veth lxc.network.link = br0
and you’re all set. As I said, piece of cake.
Slightly more difficult is to properly handle the TTY devices; some people prefer to make use of the Linux virtual terminals to handle LXC containers; I sincerely don’t want it to mess with my real virtual terminals, I prefer using the
lxc-console command to access it without networking. Especially since it messes up a lot if you are using KMS with the Radeon driver (which is what I’ve been doing for the past year or so).
For this to work out, I noted two things though: the first is that simply using the cgroup access control lists on the devices don’t help out that much (I actually haven’t tried to set them up properly just yet); on the other hand, LXC can create “pseudo-ttys” that can be used with
lxc-console; the default number (9) does not work all that well, because the Gentoo init system set up twelve virtual terminals by default. So my solution is to use my custom static device tarball and the following snippet in the configuration:
lxc.tty = 12 lxc.pts = 128
This ensures that the TTY devices are all properly set up, so that they don’t mess with your virtual terminals, and
lxc-console works like a charm in this configuration.
Now, the sad part: OpenRC is not yet stable, and I haven’t fixed yet the NFS bug I found (you stop it into the container and the host’s NFS exports are destroyed.. bad script, bad script!). On the other hand, I’m not doing LXC daily any longer for the simplest reason: the tinderbox is set up as I wish already, for the most part, so I have little to no incentive to work more on this; the good news is,
I’m up for hire as I said for what concerns Ruby. So if you really want to use LXC in production and want me to improve whatever area Gentoo-related to it, including libvirt, you can just contact me.
Beside that, everything should be in place. Have fun working with LXC!
I just noticed that Roy is not working on OpenRC any more!!!Do you know what will be the future of this in Gentoo?It is the best RC system there is comparing to any other distribution, especially the networking part (of course).
The usual.. we’ll pick it up and hope not to screw it up… more than it is.To be honest, since Roy started working on it for NetBSD, Gentoo devs (Mike and William mostly) had to take a close look upon it.. and Robin was ready to split the “oldnet” code out of OpenRC and move it on its own package for Gentoo to maintain.Maybe we’ll revert a bit of “generalisation” to suit better Gentoo (without losing FreeBSD/NetBSD support hopefully), and then we should be able to keep it running, I don’t find the situation more distressing than having a Python team that cares not about users and other devs, or the fact that I’m still maintaining PAM alone (sigh!).
Thanks!This is a relief!I never understand the new net direction… as the old is so great!One more aspect of openrc is that it works with busybox! I this is important for gentoo/embedded .I helped as much as I could for Roy to solve issues with openrc, I truly think that openrc (or baselayout-2) is much much better than baselayout-1.
bq. Maybe we’ll revert a bit of “generalisation” to suit better Gentoo (without losing FreeBSD/NetBSD support hopefully), and then we should be able to keep it running, I don’t find the situation more distressing than having a Python team that cares not about users and other devs, or the fact that I’m still maintaining PAM alone (sigh!).Good to see that at least few Linux people still care about portability. Unlike with certain other fancy init-systems where it is outright announced that portability will not be maintained even across Linux distributions.
Thanks for the interesting stuff…but could you please give some more details about the bridge (host side), and the ‘trickery’ with iptables ???