OpenVZ Forum

Home » Mailing lists » Devel » Checkpoint/Restart mini-summit
Checkpoint/Restart mini-summit [message #31933] Tue, 15 July 2008 10:49 Go to previous message
Daniel Lezcano is currently offline  Daniel Lezcano
Messages: 417
Registered: June 2006
Senior Member
Hi all,

Here is a proposition a more detailed agenda for the checkpoint/restart 
mini-summit. If everybody is ok with it, I will update the wiki.

Comments are welcome :)

	-- Daniel


The Checkpoint/restart is a very big topic and the time at the
mini-summit is short, so I propose a list of document pointers to be
read before the mini-summit, so we can address the checkpoint/restart
topic directly and save precious time :)

* Documentation
   * Zap :
   * Metacluster :
   * OpenVZ :
   * Checkpoint/Restart technology :
   * Virtual Servers and Checkpoint/Restart in Mainstream Linux : Sigops 


This section is about how to prepare the kernel to implement the

* Preparing the kernel internals
   * Identifying the kernel subsystems
   * Identifying the process resources
   * Identifying the frameworks for the CR
   * Identifying the pieces to target first

Actually, one of the big interrogation is how we transmit the internal
state to and from the kernel. There are some little patches doing the
checkpoint/restart, taking into account a small part of the kernel
resources. Some were made through netlink, others via /proc, others
directly with a syscall. There were solutions proposed in the
containers mailing list to use a core dump like file, or a CR
filesystem. This section is to discuss about that.

* Passing the kernel internal state to/from userspace
   * coredump like file
   * swap per container
   * netlinks
   * CR filesystem
   * army of different call for the CR (proc, existing syscalls, ...)

The following sections addresse the checkpoint/restart itself which
can be split into three parts: the quescient point, the checkpoint and
the restart.

* Checkpointing / Restarting

   * Reaching a quescient point
     * for the network
     * for the processes
     * for the asynchronous IO

   * Checkpoint
     * Preinstalled checkpoint signal handler ?
     * syscall ?
     * tar of a CR filesystem ?
     * monolithic ?

     * Dumping processes hierarchy
     * Identifying the kernel resource dependencies
     * Dumping system wide resources (per namespace ?)
     * Dumping process wide resources (from process context ?)
       (Memory is in between system and process resource)

   * Restarting
     * New binary format handler ?
     * Identifying the kernel resource dependencies
     * Restoring the processes hierarchy
     * Restoring system wide resources
     * Restoring process wide resources

There is a posix draft, 1003.1m, which specify a CR semantic. This can
be interesting to take it into account and provide an user API based
on this specification so we can keep in mind this when we implement
the CR in the kernel. I was not able to find the posix draft itself
but the man of the CR IRIX implementation sticks to this

* Determining the userspace API
    * Posix 1003.1m (implementation in IRIX) ?

Containers mailing list
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [PATCH][RFC] dirty balancing for cgroups
Next Topic: [PATCH 2/2] signals: replace p->pid == 1 check with a check for task_child_reaper
Goto Forum:

Current Time: Sat Mar 25 10:18:12 GMT 2023

Total time taken to generate the page: 0.00841 seconds