Changes

CPT is an extension to the OpenVZ kernel which allows to can save the full state of a running VE and to restore it later on the same or on a different host in a way transparent for to running applications and network connections. This technique has several applications, the most important being live (zero-downtime) migration of VEs and taking an instant snapshot of a running VE for later resume, i. e. CheckPoinTing.

Before CPT, it was only possible to migrate a VE through a shutdown and subsequent reboot. The procedure not only introduces quite a long downtime of for network services, it is not transparent for clients using the VE, making migration impossible migration, when clients runs run some tasks which are not tolerant to shutdowns.

Comparing to Compared with this old scheme, CPT allows to migrate migration of a VE in a way, which is essentially invisible both for users of this VE and for external clients, using network services located inside the VE. It still introduces a short delay in service, required for actual checkpoint/restore of the processes, but this delay is indistinguishable from a short interruption of network connectivity.

There is a special utility vzmigrate in the OpenVZ distribution intended to support VE migration. With it its help one can perform live (a.k.a. online) migration, i. e. for during migration the VE “freezes” for some time, and after migration it continues to work as though nothing has had happened. Online migration can be performed bywith the

command. During online migration all VE private data saved to an image file, which is transferred to the target host.

In order for vzmigrate to work without asking for a password, ssh public keys from the source host should be placed to in the destination host's <code>/root/.ssh/authorized_keys</code>file. In other words, command <code>ssh root@host</code> should not ask you for a password. See [[ssh keys]] for more info.

<code>vzmigrate</code> is not strictly required to perform online migration. The <code>vzctl</code> utility, accompanied with some file system backup tools, provides enough of power to do all the tasks.

A VE can be checkpointed with command:

This command saves all the state of a running VE to the dump file and stops the VE. If the option <code>--dumpfile</code> is not set, <code>vzctl</code> uses a default path <code>/vz/dump/Dump.VEID</code>.

After this it is possible to restore the VE exactly in to the same state executing:

If the dump file and file system is transferred to another HW node, the same command can restore the VE there with the same success.

It is a critical requirement that file system at the moment of restore must be identical to the file system at the moment of checkpointing. If this requirement is not heldmet, depending on the severity of changes , the process of restoration can be aborted or the processes inside a VE can see this as an external corruption of open files. When a VE is restored on the same node where it was checkpointed, it is enough to not to touch the file system accessible by the VE. When a VE is transferred to another node it is necessary to synchronize the VE file system before restore. <code>vzctl</code> does not provide this functionality and external tools (fi.e. <code>rsync</code>) are required.

Process The process of checkpointing can be performed by in stages. It consists of three steps.

First step – suspending suspend the VE. At this stage CPT moves all the processes to a special beforehand known state and stops VE network interfaces. This stage can be done bywith the

command.  Second step – dumping VE. At this phase stage CPT saves the state of processes and global state of VE to an image file. All the process private data need needs to be saved: address space, register set, opened files/pipes/sockets, System V IPC structures, current working directory, signal handlers, timers, terminal settings, user identities (uid, gid, etc), process identities (pid, pgrp, sid, etc), rlimit and other data. This stage can be done bywith the

command.  Third step – killing or resuming processes. If the migration succeeds the VE can be stopped with the command:

If migration failed by for some reason or if the goal was taking a snapshot of the VE state for later restore, CPT can resume the VE with:

Process The process of restoring consists of two steps.  The first step is to restore processes and to leave them in a special frozen state. After this step processes are ready to continue execution, however, in some cases CPT has to do some operations after a process is woken up, therefore CPT sets process return point to function in our module. This stage can be done bywith the

command.  Second step – waking up processes or killing them if the restore process failed. After CPT wakes up process, it performs necessary operations in our function and continues execution. This stages stage can be done bywith the