Containers are the future! and lots of misinformed talk.
The truth here is more boring. Both full-fat virtualization (KVM), and containers (LXC) are the future, and which you use will depend on what you want to do. You’ll probably use both. You’re probably using both now, but you don’t know it.
The first thing to say is that full virt and containers are used for different things, although there is a little bit of overlap. Containers are only useful when the kernel of all your VMs is identical. That means you can run 1000 copies of Fedora 18 as containers, probably not something you could do with full virt, but you can’t run Windows or FreeBSD or possibly not even Debian in one of those containers. Nor can your users install their own kernels.
The second important point is that containers in Linux are not secure at all. It’s moderately easy to escape from a container and take control of the host or other containers. I also doubt they’ll ever be secure because any local kernel exploit in the enormous syscall API is a host exploit when you’re using containers. This is in contrast with full virt on Fedora and RHEL where the qemu process is protected by multiple layers: process isolation, Unix permissions, SELinux, seccomp, and, yes, a container.
So containers are useless? Not at all. If you need to run lots and lots of VMs and you don’t care about multiple kernels or security, containers are just about the only game in town (although it turns out that KVM is no slouch these days).
Also containers (or the cgroups technology behind them) are being used in very innovative places. They are used in systemd for resource control, in libvirt to isolate qemu, and for sandboxing.
I know you are talking about LXC not being secure, but Parallels Virtuozzo has been in the wild since 2001 and OpenVZ since 2005. Both are widely deployed and if they were insecure, none of the hosting companies would be using them. OpenVZ has served me weill for ~8 years now. Here’s hoping that LXC increases its security… or really that the underlying pieces used (namespaces, cgroups, etc), get more security features.
I’m happy to see that OpenVZ have thought a lot about hardening their kernel. http://www.openwall.com/Owl/
You linked to the OpenWall Linux (OWL) distribution… which is focused primarily on security, and yes they include an OpenVZ kernel option… but OWL is not directly related to OpenVZ. Owl cares not just about the kernel but hardening all parts of the system. For example, they have redone a few things that previously needed SUIDs to work. So far as I know, they are still on RHEL5.
OpenVZ started on EL4 (now EOLed), and is currently available on EL5 and EL6… and EL7 whenever that is released. Parallels is the sponsor of the project and they are big contributors to the mainline kernel in addition to all of the work they do on their out-of-tree OpenVZ patch. In fact, Parallels has made it to the top 10 list a couple of times and frequently shows up in the top 20. They also added container features to the Microsoft Windows kernel for their “containers on Windows” product which came out in 2005. Some work has been done to make vzctl work with the mainline kernel’s LXC stuff… and it has even been packaged in the stock Fedora repo.
Pingback: Do I need OpenStack if I use Docker? | Cloudify