ZDTM test suite

ZDTM stands for Zero DownTime Migration. ZDTM test suite was developed for testing how OpenVZ live migration works. CRIU also uses this test suite.

The suite consists of many small atomic tests. Each test case creates a process, puts it into some specific state (opens a file, maps a memory segment, puts data in a pipe, etc.), then asks to be checkpointed and restored. Upon restoring, it checks that the state was preserved (file is still opened, memory is still mapped, pipe contains what was put into it, etc).

Running

All zdtm tests

You can run all the tests by:

      test/zdtm.py run -a

There's a known issue with BTRFS spoiling dev_t values for files and sockets! Not all tests will work on it.

This would run the tests in basic variation -- run the test, checkpoint, restore, check for results.

There are more variations, each is an option to the zdtm.py. Here they are:

--nocr

start tests and check results, omitting checkpoint/restore steps. Used to check that the tests themselves are working.

--norst

start the test, then checkpoint it leaving the tests running, then check the results. Used to check that checkpoint itself is not destructive.

--iter <number>

start the test, then checkpoint and restore it the <number> of times. Used to check that after restore tests are in checkpoint-able state.

--pre <number>

start the test, then do a <number> of pre-dumps, then checkpoint, restore and check results. Used to check that pre-dumps work.

--page-server

run tests, but dumps (and pre-dumps) will go through the page server.

--sibling

run tests, but restore in a so-called sibling mode. Used by LXC and Docker.

--snaps (in conjunction with --pre)

instead of pre-dumps do full dumps

--user (only works with --norst)

check how criu works when run from non-root.

Flavors

Each test can be executed in up to 3 flavors: h, ns and uns. The first is host flavor, the test is run on host and criu c/r-s it. Ns is namespace flavor, tests are run in all namespaces bu user one, criu c/r-s test with all the namespaces. The uns is usernamespace, it's like ns but with user namespace in the game.

By default tests are run on all flavors they can, but one can chose flavor with -f <flavor> option.

Specific tests

You can run a single test with

      zdtm.py run -t <test-name>

The simplest test is zdtm/static/env00. It has the bare minimal a process might have -- a little bit of memory, a signal handler and one opened file. If CRIU cannot C/R this test, it's surely cannot do anything.

You can also run only the test proggies themselves manually by issuing the

      make <testname>.pid

command. After you've done c/r-ing it you should run

      make <testname>.out

and check for the <testname>.out file contents.

If you don't want to mess with this, you can use the zdtm.py run script. When launched with the "-a" option it runs all the tests one-by-one. The exact test can be specified by a command line argument. The list command lists the tests it can run.

See also

ZDTM API