CRIU

C/R of LXC is quite a challenge :) One of the issues we've met we call "the reattach problem".When LXC tools start a container they leave a daemon process as the container's init parent, hanging around, waiting for the container to die and accepting ... [More] commands from other LXC tools (e.g. to forcibly stop the container). When we checkpoint one we leave this daemon overboard, as it's not the part of the container. And the challenge appears when we restore one.So, right after the restore, but just before we unfreeze the container to continue running we have criu process being the parent of the newly created container and orchestrating its restore procedure. After unfreeze we have two options -- either this criu master process dies, leaving the container to reparent to system init. Or criu master process stays forever waiting for the container to stop.Both ways do not result in a living LXC construction. So, in order to get the master LXC process back, there was implemented the "--exec-cmd" option to criu, which meaning is to call execv() with the given set of options after restore. The intention is to make criu master process turn into LXC master process with the execv() system call.This approach is being implemented by our contributor Deyan Doychev as we write this, and once LXC part is ready, we do the 1.3 release. [Less]

Here is a funny story for ya. Hackers and banks, all that stuff.My colleague +Andrey Wagin went into a bank. While waiting in a queue he was working on his laptop. A security guard in a uniform approached him and asked to turn the laptop off and put ... [More] it away. To a question why he answered that those small characters are scrolling down way too fast! [Less]

Some advances in the live-migration area.We have enhanced the P.Haul scripts so that they now live-migrate OpenVZ mainstream containers with any kind of private filesystem -- shared or not. In the latter case the FS is rsync-ed while the container is ... [More] running, then iterations start.The P.Haul is still very incomplete, we have lot's of stuff to do, but even in existing state it provides something to play with :) [Less]

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 ... [More] 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 namespaces2. CGroups in CT3. User-namespaces4. Timerfd5. Subreapers6. External bind-mountsIf 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. [Less]

Some news that undeservedly came unnoticed.CRIU gets integrated with the OpenMPI! It looks like that OpenMPI people like the work, so some day soon we'll see CRIU actively used not only in containers world.Kudos +Adrian Reber for taking care of that!

The 1.2 is coming :)And one of the prominent feature of it is performance improvement. We've managed to speed up dumping and restoring of a basic Centos6 container significantly -- almost 2 times each!But, as preliminary experiments show, the ... [More] OpenVZ's kernel implementation of C/R is still much faster that CRIU's. Need to set up proper performance evaluation some time soon. [Less]

And now we have the 0x1000's commit!

The 2nd candidate to 1.1 release is out!We have fixed most of the issues we've got reported after -rc1, and would like to thank everyone for it!But have some more stuff to get sorted out before we can make a good release. Thus -- the 1.1-rc2.Have fun and stay tuned!

900 more lines and we have AArch64 support in CRIU :)And, by the way, this was implemented with the help of CodeAurora people!

CRIU repo is now on GitHub as well!Join the party :)