KVM test: Virtio console - Adding migration test
commita2c73f5b0e78cf7e63d02082618ba65feac329d5
authorlmr <lmr@592f7852-d20e-0410-864c-8624ca9c26a4>
Tue, 29 Mar 2011 01:24:44 +0000 (29 01:24 +0000)
committerlmr <lmr@592f7852-d20e-0410-864c-8624ca9c26a4>
Tue, 29 Mar 2011 01:24:44 +0000 (29 01:24 +0000)
tree34d0ff25431e6d7ec267da719a36f26664b5b5bf
parentc0d60c0499e779257807cf286967d05b42da2f91
KVM test: Virtio console - Adding migration test

This patch adds migration test (tmigrate). It also daemonize the virtio_console_guest.py script, which is necessary for the migration test.

[virtio_console_guest.py]
It is splited to 2 parts, first one is client and second one is daemon.
* Daemon part is forked and works as the previous script except it redirects the STD{IN,OUT,ERR} into named pipes.
* Client part connects to named pipes and handle the communication with host OS. Also when the client is executed multiple time it finds the previous client and destrois it. Then it opens the pipes and take over the communication. The daemon is NOT executed twice.

[tmigrate]
This test transfers and checks data through virtio_console loopback while migrating the guest. It's splitted into 2 tests tmigrate_online and tmigrate_offline.
* tmigrate_{offline,online} - parses test parameters and executes the actual test __tmigrate()
* test parameters: virtio_console_migration_{offline,online} = "[{serialport,console}]:$no_migrations:send_buf_len:recv_buf_len:loopback_buf_len;..."  ; multiple tests are allowed and separated by ';'

It sends the data from first {console,serialport} and receive on all remaining ports of the same type. By default it adds 2 {console,serialport}s depends on test parameters but you can override this using no_{consoles,serialports} or the number can be higher according to other tests.

[BUGs]
Tested on: HOST=F13 (2.6.36-0.20.rc3.git4.fc15.x86_64), GUEST=F14 (2.6.35.6-45.fc14.x86_64)
Developer: is noticed simultanously with this patch for explenation.
1) console very often won't survive the migration (it stops transfering data).
virtio_console_migration_offline = "console:5:2048:2048:2048"
2a) offline migration: drops 1-2 send-buffers of data, which is for now accepted as success.
virtio_console_migration_offline = "serialport:5:2048:2048:2048"
2b) Using smp2 the data loss is 1-4 send-buffers of data.
only smp2
virtio_console_migration_offline = "serialport:5:2048:2048:2048"
3) online migration: similar problem as offline but the data-loss is much higher and depends on the console throughput. In this version very high value is accepted as pass. You should check the message "Maximal loss was %s per one migration". If it should be n-degree lower than the transfered data.
virtio_console_migration_online = "serialport:5:2048:2048:2048"
4) ThSendCheck sometimes get stuck in send. Test handle this and the problem is similar to: the "FIXME: workaround the problem with qemu-kvm stall when too much data is sent without receiving". Using migration this occures with even smaller slices.
virtio_console_migration_offline = "serialport:5:4096:1:1"

Signed-off-by: Jiri Zupka <jzupka@redhat.com>
Signed-off-by: Lukas Doktor <ldoktor@redhat.com>
git-svn-id: svn://test.kernel.org/autotest/trunk@5290 592f7852-d20e-0410-864c-8624ca9c26a4
client/tests/kvm/scripts/virtio_console_guest.py
client/tests/kvm/tests/virtio_console.py
client/tests/kvm/tests_base.cfg.sample