Posted
about 11 years
ago
Hello, everyone!We are glad to announce the 6th release of the checkpoint-restore tool, which this time has a lot of bug fixes and a bunch of new features!We think that at this point we'd version this release as v1.0-rc1, since the tools are about to
... [More]
be stable and feature-full enough to be announced as v1.0. The current plan is to release the v1.0 before the upcoming Linux Kernel Summit, that would happen at the end of October.Thank you and stay tuned! [Less]
|
Posted
about 11 years
ago
Some small improvement for the "exec" command. Now it also supports syscalls' argument, in which kernel puts some data back, e.g. the 2nd argument to the read() system call. To do this provide the "@" arg in the command line in the respective place.See http://criu.org/Remote_syscall_execution for details.
|
Posted
about 11 years
ago
And one more soon-to-be-upstream stuff merged -- the posix-timers API extensions are in so called tip-tree and thus soon should be at Linus.So, the timers in question are those created with timer_create() system call. The API for working with them so
... [More]
far has been write-only -- an application was supposed to know for sure what timers it has created and how. Such types of API is a big problem for checkpoint-restore tool, as when it comes to dump a process it has no information about what timers take part in its life cycle, and there's no chance to find this out from the task.Thus, we have proposed an extension to the timers API -- that is a simple /proc fie, that lists timers and some info about them. With this we can properly dump them and restore later.With this API merged, the project comes the state when it can actually find out everything about a Linux process. So hopefully, some time soon we'll be able to make the first stable release of the tool! [Less]
|
Posted
about 11 years
ago
So, Andrew Morton has merged into his tree kernel patches, that help us to monitor how tasks change their memory! What it gives to +CRIU ? Quite a lot.For example right now we have a --snapshot option for crtools, that allows us to take incremental
... [More]
dump from a process tree, that was dumped previously. For example, for a VNC server with mplayer playing a movie, the size of first dump is 39M, while the second (incremental) dump taken in 30 seconds after it weights "only" 8.2M.Another reason why we wanted this is so called "iterative migration" -- in this type of live migration we first copy all tasks' memory on the destination node, then freeze the processes and copy only what has changed. With this the freeze time for e.g. the vnc+mplayer on 100Mb network would decrease from 4 seconds to less than one (and even less, if we do more than one "iteration").The feature is very new and not yet finished (and not yet documented :)), but what we already have is great. If the kernel patches will happen to be in v3.10 that would be awesome! [Less]
|
Posted
about 11 years
ago
When people first try to play with CRIU what they do is try to run a busy-loop in shell and dump one. Such a trivial scenario doesn't just work and that's why.When one runs a program from shell (which is turn runs under e.g. xterm), the former one
... [More]
is launcheda) inside session whose leader is shellb) with a terminal opened in stdios which is attached by its other end to xtermHaving both of the above true, crtools refuse to dump the program saying thata) session leader is alive, but is not taken into dumpb) one terminal end is opened by external program which is also not taken into dumpIn order to address this there are two waysThe aay A is to remove external dependencies by using setsid command and redirecting stdio-s to files. The way B is in using the --shell-job option that asks crtools to consider external session and terminals to be OK.Both of the scenarios are describes in more details in a new HOWTO page at http://criu.org/Simple_loop . This document is a good starting point if you try to play with CRIU :) [Less]
|
Posted
about 11 years
ago
Update to v0.8
|
Posted
about 11 years
ago
Update to v0.8
|
Posted
about 11 years
ago
Dumping VNC with app inside is trickier than it seems to be. We've prepared a HOWTO page describing how this can be done:http://criu.org/VNCTwo main problems with VNC dump is that X uses system V IPC to work, so an IPC namespace should used, and
... [More]
that it may share session and terminal with shell, so it should be started in a new session with redirected stdio-s. The article describes how this can be done. [Less]
|
Posted
about 11 years
ago
I hope you were intrigued with the news about VNC + others got dumped by CRIU :) Here's the demonstration of how this all happened, this time using video player playing a movie about a fire-bird (CRIU mascot).
|
Posted
about 11 years
ago
Soon after Libre-Office checkpoint and restore we've tried some other X applications. First they seemed to hung after restore, but after changing the VNC client the problem disappeared.So, the current list of tested apps withing VNC server is*
... [More]
Libre-Office writer* Gimp* Inkscape* Blender* IceWM* XScreensaver (this one was even demonstrated on one conference)We've also tried to checkpoint Firefox, but it opened a unix-stream connection to the host dbus daemon, so we couldn't dump one. Need more work on the environment we use for it.And, during the tests there was a VNC client connected to the server and interacting with the working application :) [Less]
|