Integration
CRIU is not so easy to be used as a standalone tool -- it works best integrated into other software. This page lists such software and provides details about the current status.
Container platforms
Virtuozzo/OpenVZ
Status: ready
Currently, vzctl supports CRIU for checkpoint/restore of upstream containers (i.e. when non-OpenVZ kernel is used). Commands vzctl suspend and vzctl restore fully work. Live migration doesn't work yet as it requires support for vzctl suspend {--suspend, --dump, --kill, --restore} which is not yet implemented as it requires a separate daemon to hold the state of a partially checkpointed container (or an ability from criu tool to do that).
- Project homepage
- Relevant vzctl git commits
- Virtuozzo is a virtualization and automation solution built on top of OpenVZ.
LXC/LXD
Status: ready
- Project homepage
- The tools version 1.1.0 fully supports CRIU to C/R LXC containers
- lxc-checkpoint man page
See also: LXC
Docker
Status: ready
- Project homepage
- Merged into libcontainer/runc
- Merged into Docker itself
- Preparations efforts done by Saied Kazemi
See also: Docker C/R
CoreOS Rocket
Status: not started
Tools and utilities
The file utility
Status: ready
- Starting from v1.6 new images (v1.1) will be generated
- File utility starting from 5.23 will support these
Screen/TMUX
Status: stalled
- Jerome did this some time ago
Shell
Status: not started
It would be nice to have bash (or other shell) to launch criu with --restore-sibling option and get new kid processes from it. Right now we workaround it with "shell jobs".
Other
OpenMPI
Status: stalled
- Adrian Reber did first version of patches
Subgraph OS
Status: not started
- Subgraph OS is a desktop operation system uses containers for users applications.
SLURM workload manager
Status: ready
- Project homepage here
- Integration code on the github
Wayland/Weston
Status: stalled
- Ruslan Kuprieiev plans to patch Weston to let CRIU C/R graphical apps
See also: X applications
Systemd
Status: not started
Adrian suggested that migrating processes from one system to another works, depending on the process, pretty good. Migrating a process under systemd's control might be possible by just killing the process on the source side but it cannot become a child process of systemd on the destination of the migration without systemd knowing how to restore a process and thus making it a child process of systemd (--restore-sibling).