Difference between revisions of "Integration"

From CRIU
Jump to navigation Jump to search
(+podman)
m (Drop CoreOS Rocket)
Line 32: Line 32:
 
* [https://podman.io/ Project homepage]
 
* [https://podman.io/ Project homepage]
 
* [https://podman.io/blogs/2018/10/10/checkpoint-restore.html Blog entry about adding the support]
 
* [https://podman.io/blogs/2018/10/10/checkpoint-restore.html Blog entry about adding the support]
 
=== CoreOS Rocket ===
 
{{Status|not started}}
 
  
 
== Tools and utilities ==
 
== Tools and utilities ==

Revision as of 10:02, 17 September 2021

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

As of Virtuozzo/OpenVZ 7, CRIU is fully integrated and supported. Older OpenVZ releases used in-kernel checkpoint/restore functionality, now superseded by CRIU.

LXC/LXD

Status: ready

See also: LXC

Docker

Status: ready

See also: Docker C/R

Podman

Status: ready

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

See also: Screen

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".

See also: 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

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).