----- "sudhir kumar" <smalikphy@xxxxxxxxx> wrote: > 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. I think generally kvm_tests.cfg is flexible enough, and can easily be modified to define whatever you like. Note, however, that the config file parser module is only responsible for producing a list of dictionaries which define the tests to run. It doesn't care much about parallelism -- this is up to the control file and the rest of the framework. If you're not familiar with the format of config files, please refer to http://www.linux-kvm.org/page/KVM-Autotest/Test_Config_File and http://www.linux-kvm.org/page/KVM-Autotest/Parameters > In this scenario my system will be having N VMs, all running the same > set of testcases. I thought you said one VM running migrate and dbench in parallel. I'm not sure I follow. > 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. This seems like two tests to me: dbench with dbench (several instances), and then another unrelated bonnie test. Also note that the variants you select with 'only' must be defined before they can be selected. Look at the examples in the wiki as well as real config files. > 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. Regarding parallelism: Generally two types can be implemented. 1. Several independent test execution queues: in this case there are several queues that don't interfere with each other. Each queue works with its own VMs. This is useful for saving time by running tests in parallel on capable hosts. This can be implemented using job.parallel() and is already running in TLV. I will try to post the patches soon. This can probably also be implemented from the server, if it can treat a single physical host as if it were several, thus running several independent copies of the Autotest client on it. 2. Several tests on a single VM, which is what you were referring to, if I understood correctly: in this case several threads work with the same VMs and abuse them in parallel -- one thread can run dbench while the other runs migration on the same VM. This is possible using threads, and the syntax in the config file can be something like 'types = dbench migration' instead of what we currently use -- 'type = dbench'. However, we have to think whether we really just want to run tests in parallel. In the migration-dbench case, for example, we'd like to make sure dbench starts running before we migrate. So maybe it's wiser to just run some load inside the migration test, instead of the dbench test. We should carefully consider all options. Thanks, Michael -- 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
