CRIU

Update to 1.0

Update to 1.0

One more application of +CRIU . If you're playing a game, that doesn't have a "save" function at some place, you can save the state by dumping it  :DI've just done it with VNC + SuperTux and, in addition, did this in a two-steps manner by doing ... [More] pre-dump and then dump. In the middle of the game pre-dump generated 90M of images and subsequent dump -- 14M. Frozen time didn't differ much, since all the images fit into my box's page cache and were written "really fast". [Less]

Some numbers concerning optimized freeze time with the help memory tracking. We have a test in zdtm test suite, which creates a big mapping (512 Mb) and populates it with pages. This test is used to demonstrate how memory tracking can speed dumping ... [More] huge apps.First, we start this test and just dump it. The freeze time is 7.7 seconds, 7.6 of which criu writes pages into image file.The 2nd experiment is two step -- first we use criu pre-dump action, that grabs memory from task, turns memory changes tracking, unfreezes task and only after this starts writing its memory into image file. After this we perform regular dump, asking criu not to dump pages, that hasn't changed since previous dump (well, pre-dump). In this scenario the timings are much more application-friendly :) The total freeze time is 0.1 second (0.05 for pre-dump and 0.05 for dump steps) since the big time (~7 sec) spent for wiring pages into images it done while application is running.If we look at the image file, that describes memory pages layout (pagemap.img) we'd see, that after pre-dump we have 8 regions 16384 pages each (512 Mb), while the update on this image, created on dump stage would show, that we have all those pages present in "parent" image set, just as expected :)This test is in criu source tree -- the test/mem-snap/run-predump-2.sh script is quite small and does all the above steps. [Less]

So, several features that use memory changes tracking are finally working in CRIU tool! Sad news is that the respective kernel changes are still in -mm tree, so our kernel with applied patches should be used instead.That said, meet the incremental ... [More] dumps (http://criu.org/Incremental_dumps)and iterative migration (http://criu.org/Iterative_migration)! [Less]

The 0.5 is out!No new cool features, that work on Linux-3.9, since we mostly focused on bug fixing (thanks to all who played with the tool and reported those to us), but with the custom kernel (patches are expected to get merged into Linux-3.10) we ... [More] can do various new things, like incremental snapshots, C/R netlink sockets and a little bit more :)Have fun! And sorry in advance if we are not very responsive in the nearest days -- there are long holidays in Russia in the beginning of May. [Less]

We've promised lots of news, so here's one more.The amount of lines of CRIU code (without tests) is now above the 40K value! A historical note -- the v0.1 released about a year ago was two times smaller -- slightly bigger than 20K.

Version 0.7 is out now!It includes some new features, like TUN devices, shared mounts and sigaltstack support, as well as quite a lot of bugfixes.But the main news item is, as of kernel 3.11, we have finally merged upstream all the critical ... [More] CRIU-related features! So from now on we will concentrate on the tool stability and performance, and we are no longer needed to sync our  releases with the kernel releases, as we did before.Therefore, the next release will come out earlier than in 2 months and will (should) contain a big bugfix set. New features will also be added, of course, we'll share our plans next time.Have fun! [Less]

In the next release CRIU will provide one more API for ... programmers!Currently CRIU can only be run as a command-line tool. This is very handy to be used in scripts, but when it comes to C, Python, Java or any other programs, spawning a process and ... [More] exec()-uting the tools is possible, but not extremely elegant.So to make life easier we introduce a simple RPC API in CRIU. The RPC  is protocol-buffer-based, so it should be relatively easy to use one with any modern language. Two examples -- for C and Python -- of how to use the RPC are in $sources/test/rpc/ directory.Have fun! [Less]

It was quite obvious, that we could trigger some internal application bugs when doing checkpoint/restore on them. Surprisingly we've faced this only once and on a single box.The problem occurred with tiger-VNC server. If connection gets "broken" for ... [More] a while, dropping packets, and client re-sends a bunch of events "at once", the server stops responding for arbitrary long time.The "connection gets broken" is what we do during dump and restore -- we block TCP connection with iptables in order to repair the connected socket carefully (http://criu.org/TCP_connection). So, after we restore server and "fix" connection back, client side re-sends a bunch of events. It does so since we continue to "work" with the client, it sends these events to server, but TCP stack doesn't get any ack-s on them due to locked connection.When server sees this influx it tries to deal with it, drops many events, extends it's event queue but (!) does not respond back till it thinks it's ready. While we keep working with client server may stay unresponsive. We've seen it being stuck for several minutes.This should be another reason for us to try making the live-migration freeze time extremely small :) [Less]