Difference between revisions of "ZDTM test suite"
Line 37: | Line 37: | ||
;--user (only works with --norst) | ;--user (only works with --norst) | ||
: check how criu works when run from non-root. | : 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 <code>-f <flavor></code> option. | ||
=== Certain test === | === Certain test === |
Revision as of 10:10, 25 March 2016
Description
ZDTM stands for zero-down-time-migration. It's test suite developed for testing how OpenVZ live migration works. We use this test suite for checking how criu do their job. The suit consists of many small atomic tests -- each puts a process into some "state" (opens a file, maps a memory segment, puts data in a pipe, etc.), then asks to be checkpointed and restored. The in checks that the "state" was preserved (file is still open, memory is still mapped, pipe contains what was put into it).
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
- would do start test and check results. User to check that test themselves are working.
- --norst
- would start the test, the checkpoint it leaving the tests run, then check the results. Used to check that checkpoint is not destructive.
- --iter <number>
- would start the test, then would checkpoint and restore it the <number> times. Used to check that after restore tests are in checkpoint-able state.
- --pre <number>
- would statr the test, then do <number> pre-dumps, then checkpoint, restore and check results. Used to check that pre-dumps work.
- --page-server
- would run tests, but dumps (and pre-dumps) will go through the page server.
- --sibling
- would run tests, but restore would happen in 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.
Certain test
You can run a single test with
zdtm.py run -t <test-name>
or you can 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 runs all the tests one-by-one. The exact test can be specified by the command line argument. The list
command lists the tests it can run.