On Wed, May 13, 2009 at 11:30 PM, Michael Goldish <mgoldish@xxxxxxxxxx> wrote: > > ----- "sudhir kumar" <smalikphy@xxxxxxxxx> wrote: > >> Hi Uri/Lucas, >> >> Do you have any plans for enhancing kvm-autotest? >> I was looking mainly on the following 2 aspects: >> >> (1). >> we have standalone migration only. Is there any plans of enhancing >> kvm-autotest so that we can trigger migration while a workload is >> running? >> Something like this: >> Start a workload(may be n instances of it). >> let the test execute for some time. >> Trigger migration. >> Log into the target. >> Check if the migration is succesful >> Check if the test results are consistent. > > Yes, we have plans to implement such functionality. It shouldn't be > hard, but we need to give it some thought in order to implement it as > elegantly as possible. I completely agree here. > >> (2). >> How can we run N parallel instances of a test? Will the current >> configuration be easily able to support it? > > I currently have some experimental patches that allow running of > several parallel queues of tests. But what exactly do you mean by Please post them. > "N parallel instances of a test"? Do you mean N queues? Please provide > an example so I can get a better idea. I wanted a parallelism in 2 degrees. Let me try with an example. The following test only raw.*ide.*default.*smp2.*RHEL5.3.i386.*migrate.dbench is just one instance and will create one VM with given specifications and execute migrate and dbench. So I am thinking how can we trigger n similar tests execution in parallel. I feel job.parallel() is meant for that but is kvm_tests.cfg good enough to be used under such a scenario? However we have most of the stuff non static(as getting the free vnc port, etc) but still we have some variables which are static. For ex. vm name, migration port etc. So what are your thoughts on it. In this scenario my system will be having N VMs, all running the same set of testcases. On the other hand I was looking for something like this as well. only raw.*ide.*default.*smp2.*RHEL5.3.i386.*migrate.dbench.dbench_instancesN.bonnie Thus all the tests will be executed in normal way except dbench. There should be running N instances of dbench and when over simply run bonnie and exit. I hope my demand to kvm-autotest is not too much but for an effective and rigorous testing of kvm such a framework is necessary. I am bit new to autotest framework and have very little knowledge of the server side. I will start spending some time on looking at the available features. Hope I was clear this time. -- Sudhir Kumar -- 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