On 02/15/2012 08:41 PM, tangchen wrote: > Hi guys~ > > Isn't it a problem to you guys? > > And one more thing. > The program architecture limits that whatever option I want to test, > I always have to migrate the vm to destination and migrate it back. > But what if I only want to test once? > > So I'm thinking maybe we can change the test flow like this: > 1. construct a migrate command. > 2. migrate vm to destination. > 3. destroy and undefine(if necessary) vm on destination. > 4. recover source host environment. > > How about that? Please comment, thanks! :) > > On 02/13/2012 05:01 PM, tangchen wrote: >> Hi Chris~ >> >> There may be a little problem in virsh_migrate.py test. >> >> I did the test with the following environment: >> source host: 192.168.1.40 >> destination host: 192.168.1.30 >> >> I cancelled the test when "there" had finished, but "back" didn't start. >> The second time I run the test, I got this error: >> >> ERROR| Start VM vm1 failed: >> Command</usr/bin/virsh -c qemu+ssh://192.168.1.30/system start vm1> failed, >> rc=1, Command returned non-zero exit status >> * Command: >> /usr/bin/virsh -c qemu+ssh://192.168.1.30/system start vm1 >> Exit status: 1 >> >> I found that when "there" was finished, vm.connect_uri was set to >> 192.168.1.30, and it remained. >> So "there" and "back" must be run in pairs. >> >> I am wondering if this is a good idea. If there is something wrong within >> "there", the environment will be changed. >> And the other tests may be influenced. >> >> >
Hi, Thanks for the feedback. The problem you found WRT canceling the test is one I hit several times. It has to do with the tests/libvirt/env file persisting. I spoke with lmr about this because I was thinking maybe for stand-alone client testing, the env file should not persist unless requested. When I was hacking on this stuff, in-between runs I did: rm -rf results; tools/make_clean; rm -f tests/*/env; reset Clearly it wasn't just me having problems with env file, so this probably needs fixing more urgently. I'll open up an issue on it so we don't forget. --- On your other note, yes, you're right, this may not be expected. I choose for safety's sake to make the default migration use --undefinesource --persistent. This will 'move' the VM definition to the destination during testing. This is to prevent accidentally starting up the guest on two hosts at the same time (which will silently corrupt it's storage). Also, I think we shouldn't assume destination host state in-between autotest runs. For repeat, uni-directional migrations, just remove those options from virsh_migrate_options. Then the guest definition will 'copy' instead of 'move' to the destination. In fact, since you bring it up, let's make a test-variant for this with some comments. That will satisfy all use-cases and better document the default behavior. Thanks for mentioning these things! -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
