Re: kvm-autotest: The automation plans?

[jason wang <jasowang@redhat.com>]

Michael Goldish 写道:
> ----- "sudhir kumar" <smalikphy@gmail.com> wrote:
>
>   
>> On Thu, May 14, 2009 at 12:22 PM, jason wang <jasowang@redhat.com>
>> wrote:
>>     
>>> sudhir kumar 写道:
>>>       
>>>> 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.
>>>>
>>>>         
>>> We have some patches of ping pong migration and workload adding.
>>>       
>> The
>>     
>>> migration is based on public bridge and workload adding is based on
>>>       
>> running
>>     
>>> benchmark in the background of guest.
>>>       
>> Cool. I would like to have look on them. So how do you manage the
>> background process/thread?
>>     
Yes, we would try to sent it here as soon as possible. The background 
workload could be added through various methods. We could an simple 
algorithm as follows:

run_migration2():
pid = run_autotest_background(test,params,env,"dbench","control.60")

Do ping-pong migration ...

wait_autoteset_background(pid)

run_autotest_background() would fork a subprocess to run function 
run_autotest() and catch its exception.
wait_autotest_background(pid) would wait until the background benchmark 
complete and analyse the result through the return value of the subprocess.
The child process could work well depends the fact that the ssh 
connection should alive during migration.
I believe this could be also achieved through job.parallel()
>>>> (2).
>>>> How can we run N parallel instances of a test? Will the current
>>>> configuration  be easily able to support it?
>>>>
>>>> Please provide your thoughts on the above features.
>>>>
>>>>
>>>>         
>>> The parallelized instances could be easily achieved through
>>>       
>> job.parallel()
>>     
>>> of autotest framework, and that is what we have used in our tests.
>>>       
>> We have
>>     
>>> make some helper routines such as get_free_port to be reentrant
>>>       
>> through file
>>     
>>> lock.
>>> We've implemented following test cases: timedrift(already sent
>>>       
>> here),
>>     
>>> savevm/loadvm, suspend/resume, jumboframe, migration between two
>>>       
>> machines
>>     
>>> and others. We will sent it here for review in the following weeks.
>>> There are some other things could be improved:
>>> 1) Current kvm_test.cfg.sample/kvm_test.cfg is transparent to
>>>       
>> autotest
>>     
>>> server UI. This would make it hard to configure the tests in the
>>>       
>> server
>>     
>>> side. During our test, we have merged it into control and make it
>>>       
>> could be
>>     
>>> configured by "editing control file" function of autotest server
>>>       
>> side web
>>     
>>> UI.
>>>       
>> Not much clue here. But I would like to keep the control file as
>> simple as possible and as much independent of test scenarios as
>> possible. kvm_tests.cfg should be the right file untill and unless it
>> is impossible to do by using it.
>>     
>>> 2) Public bridge support: I've sent a patch(TAP network support in
>>> kvm-autotest), this patch needs external DHCP server and requires
>>>       
>> nmap
>>     
>>> support. I don't know whether the method of original
>>>       
>> kvm_runtes_old(DHCP
>>     
>>> server of private bridge) is preferable.
>>>       
>> The old approach is better. All might not be able to run an external
>> DHCP server for running the test. I do not see any issue with the old
>> approach.
>>     
>
> We're taking more of a minimalist approach in kvm_runtest_2: the
> framework should handle only the things directly related to testing.
> Configuring and running a DHCP server is and should be beyond the scope
> of the KVM-Autotest framework. To emulate the old behavior, you can just
> start the DHCP server yourself locally. If you wish, maybe we can
> bundle example scripts with the framework that will do this for the user,
> but they should not be an integral part of the framework in my opinion.
>
>   
>>
>> -- 
>> Sudhir Kumar
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>