We often say, that one of our goals is to support C/R of Linux containers. Sometimes people try to dump a container created with LXC tools and most often the attempt fails. Let me shed some light on the issue.

There are several ways to create a container on Linux.

One is -- to use OpenVZ vzctl tool. Since version 4.6 it is possible to do it without replacing your distribution kernel with the OpenVZ's one. For example, in Fedora-19 vzctl package can be installed using yum and right after that one can run containers.

Another popular way is to use LXC tools. They also work on more or less modern upstream and distributions' kernels.

So, with either vzctl or lxc one can create a container, but the thing is -- both tools work on slightly different guest distributions (templates) and configure the containers in two different ways.

The LXC tool tends to work on very recent distributions, uses all recent advances of the kernel Containers API and creates container, that has connections to the host (e.g. -- console). The vzctl tool is more conservative in the templates support, uses only minimally required kernel API and creates more isolated container.

Having said that, CRIU now has support for all the stuff, that vzctl creates in container, right now it's even possible to live-migrate a container created with vzctl on Fedora using the P.Haul tool (http://criu.org/P.Haul). But we have more to do to support LXC container. What is it?

1. Nested mount namespaces
2. CGroups in CT
3. User-namespaces
4. Timerfd
5. Subreapers
6. External bind-mounts

If you create a container with LXC tool without all of the above (i.e. -- the way OpenVZ does), it will be possible to C/R such CT. But this is treated as non-standard configuration by LXC.

So, once we finish supporting the stuff above, it will be finally possible to C/R and live-migrate even LXC and hopefully Docker containers without additional modifications of the CT's configuration.
Shared publiclyView activity