CRIU

We have just added the http://criu.org/Powered_by page with nice 88x31 buttons you can use on your web site to show your appreciation to CRIU. It'd be great if you link the button back to criu.org web site.

Some time ago we've tested how crtools dump and restore a VNC server with a simple screen-saver running in it and an active client watching it on remote host. This time we took a little bit more useful application -- Libre Office Writer.And it did ... [More] work without any additional changes in crtools code!However, several precautions had to be taken before running the app to make it work smoothly. First, it was launched in an IPC namespace to let crtools properly handle the SysVIPC shared memory segment. We also run it in a new PID namespace to avoid problems with pid restore (sometimes pid to restore a task with is busy on host) and both -VNC server and Writer app - were run from one shell script so they have a common ancestor, which is not init.And, as in previous experiment, a VNC client was connected to the server and for it the dump+restore looked like a small delay in service. [Less]

Update to 0.7

More people are trying to play with crtools :) And although it's cool by itself, it's also nice, that we are getting to know what problems people usually meet. From what I see now, almost everybody first meet the so called "external unix socket" ... [More] thing, so here's yet another FAQ entry:Q: What is "external unix socket" I see in dump/restore logs?A: When you try to dump a process sub-tree, crtools tries to make sure, that the image it produces is "self-contained". This means, that if object A references another object B, and A goes into dump, then B should be dumped as well. For example, if we have a pipe, and we dump its one end (object A), because it belongs to process we dump, we should also dump its other end (object B), iow -- we should take process owning B into image as well. Or, if we have a unix socket (A) that is connect()-ed to some other one (B), and we dump socket A, because it's opened by a process we dump, we should also dump socket B and the task it's owned by. Maybe B gets dumped some time later, but it anyway should.This restriction is applied to make sure that after restore we have applications continue working, rather than e.g. receiving SIGPIPEs due to half-closed pipes or sockets.That said, "external unix socket" in logs mean, that crtools found a unix socket connected to another one, but that another is not dumped, because it's owned by a process not going into the image.However, sometimes we can dump one half of a unix socket pair. From what we've seen from users, there's a logd daemon, that opens a datagram unix socket and waits for messages on it to put them into some log file. Other processes create a datagram unix socket as well and connect it to the logd's one. Such datagram unix connection is thus uni-directional, iow -- logd's socket remains unconnected. In this case we can dump a program, that is a client to logd, we just have to connect its socket back to logd during restore using the logd's socket name.And this is when --ext-unix-sk option should be used. By providing this option for both dump and restore commands one states "I know there may be uni-directional unix connections, and I will make sure the server end will exist on restore". When this option is used, crtools will put into the image file with unix sockets info about the "external" socket met and will try to re-connect sockets back to it on restore.There are other cases with such "external resources", you can find more examples here: http://criu.org/Advanced_usage [Less]

- Update to 0.7 ( changelog: http://criu.org/Releases#v._0.7 )

The v0.7 is out!It includes some new features, like TUN devices, shared mounts and sigaltstak support, as well as quite a lot of bugfixes.But the main news is -- we have finally merged upstream all the critical for C/R stuff! So from now on we ... [More] concentrate on the tool stability and performance and we will no longer have to sync our  releases with the kernel releases, as we did before.Thus the next release will come out sooner, than in 2 months and will (should) contain a big bugfix set. New features will also appear, of course, I'll talk about the plans next time.Have fun! [Less]

When the CRIU project started, +Adrian Reber noticed, that it might make perfect sense to teach crtools to live-migrate applications without putting images on any intermediate storage not to create additional load on it. At that time it was quite ... [More] complex to properly implement this, but now we've made one step towards it.Briefly, in order to live-migrate an application, one should dump it, bring images on other node and restore it there (also caring about having the file-system in-sync). To do the disk-less live migration, it looks natural to keep images in tmpfs, all the more so they should be quite small. That's true, they are small, but there's one image file that can be VERY big -- it's the image with applications memory. And keeping this one in tmpfs is only acceptable on destination node, since we're about to settle the application there anyway. For source node, keeping two copies of apps data is not good.So, the recent changed in CRIU introduce a so called "page server". This guy starts on the destination node and waits for crtools from the source node to send him the pages with data. Then it will put them into the images directory (tmpfs one) as if they were regular crtools images. After this, it's possible to copy the rest from source node, go to destination one and restore tasks there! That's it.In the (nearest I hope) future, when we teach kernel to help us track how applications change their memory, we will be able to reduce the freeze-time of live-migration by sending the full set of apps memory to the page server before freezeing the apps and sending to it the changed data after freeze.And, since I mentioned the memory change tracker, with this we will finally be able to implement incremental checkpoint in CRIU :)Have fun! [Less]

One of CRIU's goals is to live-migrate one end of a TCP connection. In the OpenVZ kernel this was done by getting all the information about the connection from the respective kernel structures. With CRIU's approach this couldn't be implemented, as ... [More] TCP socket internals were not available for user-space direct access.Thus, we have developed and merged the TCP repair mode. Briefly, in this mode a TCP socket can be "tuned" in any way without sending any data, that may be required by the protocol, to the network. E.g., when calling connect() on a TCP socket under repair, the socket in question will be immediately switched into ESTABLISHED state with peers credentials set to values provided by the connect() arguments, without doing the protocol-defined 3-way handshake.However, the first implementation of the repair mode turned out to be incomplete. TCP can negotiate usage of time-stamps on packets, and this time-stamp for every new packet is generated from the kernel-wide constantly growing variable. Thus, if we try move a repaired socket from one machine on another the time-stamps will not fit to each-other and the connection may terminate.When this was noticed, the repair mode manipulations were extended with the ability to specify a time-stamp offset on a TCP socket, that will be applied to outgoing packets. With this patch merged into 3.9-rc1, CRIU can now actually live-migrate a TCP connection!However, time-stamps is only one of several known problems with TCP sockets. You can find more at http://criu.org/TCP_repair_TODO, but nonetheless, the real blocker for sockets migration is now fixed :) [Less]

Only a couple of weeks ago the crtools package was the candidate for Fedora 19, and now it's accepted as the new Fedora feature!

New crtools release is available! As was planned, right after the Linux-v3.8 goes the crtools-v0.4.The coolest thing about this release is that now crtools doesn't require a custom kernel to have all its features working! Another great thing is the ... [More] ARM port, so crtools is no longer x86-64-oriented project.Other than this the list of changes is still large :) We've tuned the build system heavily, made it possible to collect the code coverage stats, made the namespaces detection automatic and, of course, added support for a whole bunch on new in-kernel states of tasks!So, give it a try and have fun! [Less]