Michael Goldish writes: > On 09/25/2010 11:36 AM, Jason Wang wrote: > > We could give a further test of migration by launch test during migartion. So > > the following series implements: > > > > - A simple class to run a specified test in the background which could be used > > to launch other test during migartion. Its design is rather simple and its usage > > is a little tricky, but it work well. > > - Two sample tests which take advantages of the background class: Test reboot > > during guest migration and test file_transfer during guest migration. > > > > In the future, we could even lauch autotest client test during guest migation. > > > > --- > > > > Jason Wang (3): > > KVM Test: Introduce a helper class to run a test in the background > > KVM test: Test reboot during migration > > KVM test: Test the file transfer during migartion > > > > > > client/tests/kvm/kvm_test_utils.py | 44 +++++++++++++++ > > .../kvm/tests/migration_with_file_transfer.py | 59 ++++++++++++++++++++ > > client/tests/kvm/tests/migration_with_reboot.py | 45 +++++++++++++++ > > client/tests/kvm/tests_base.cfg.sample | 12 ++++ > > 4 files changed, 159 insertions(+), 1 deletions(-) > > create mode 100644 client/tests/kvm/tests/migration_with_file_transfer.py > > create mode 100644 client/tests/kvm/tests/migration_with_reboot.py > > It seems to me that this method is only applicable to tests/functions > that don't require a VM object (i.e. that require only a shell session > object). kvm_test_utils.reboot() operates on a VM object, and the same > VM is destroyed by migrate() which runs in the background, so eventually > reboot() tries logging into a destroyed VM, which fails because > vm.get_address() fails. Any monitor operation will also fail. If the > autotest wrapper requires a VM object (currently it does) then it can't > be used either. > You are right and that's an issue when running test in parallel with migration, but reboot through shell should work. The aim of this kind of test is just to add some stress ( such as run_autotest) during migartion, so most (probably all) of the tests only needs a session. So I think it's not a very big issue in this situation. > An alternative (somewhat ugly) way to migrate in the background is to > pass a boolean 'migrate' flag to various functions/tests, such as > reboot() and run_autotest(). If 'migrate' is True, these functions will > do something like > > vm = kvm_test_utils.migrate(vm, ...) > > in their waiting loops, where wait_for() is normally used. This > guarantees that 'vm' is always a valid VM object. For example: > > # Log in after reboot > while time.time() < end_time: > if migrate_in_bg: > vm = kvm_test_utils.migrate(vm, ...) > session = vm.remote_login() > if session: > break > time.sleep(2) > > This is much longer than the usual wait_for(...) but it does the job. > What do you think? This makes sense but it would let testcases need to care about the migration and it's also hard to put all related codes into a wrapper which would complicate the codes. Despite the issue of vm object, all tests that only depends on the shell session should works well with my method and it's more easy to be extended. Maybe we could just warn the user of its usage and adapt my method? > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
