Changes

== Description ==

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

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 does its job. The suite consists of many small atomic tests. Each such test 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. 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 ==

== Running ==

=== All zdtm tests ===

=== All zdtm tests ===

You can run all the tests by:

You can run all the tests by:

       test/zdtm.py run -a

       test/zdtm.py run -a

;--nocr

;--nocr

: would do start test and check results. User to check that test themselves are working.

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

;--norst

;--norst

: would start the test, the checkpoint it leaving the tests run, then check the results. Used to check that checkpoint is not destructive.

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

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

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

;--pre <number>

: would statr the test, then do <number> pre-dumps, then checkpoint, restore and check results. Used to check that pre-dumps work.

: 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

;--page-server

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

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

;--sibling

;--sibling

: would run tests, but restore would happen in so called ''sibling'' mode. Used by LXC and Docker.

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

;--snaps (in conjunction with --pre)

;--snaps (in conjunction with --pre)

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

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

=== Certain test ===

=== Specific tests ===

You can run a single test with

You can run a single test with

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

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

If you don't want to mess with this you can use the <code>zdtm.py run</code> 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 <code>list</code> command lists the tests it can run.

If you don't want to mess with this, you can use the <code>zdtm.py run</code> 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 <code>list</code> command lists the tests it can run.

[[Category:Development]]

[[Category:Development]]

[[Category:Testing]]

[[Category:Testing]]