Re: kvm-autotest: The automation plans?

[jason wang <jasowang@redhat.com>]

sudhir kumar 写道:
> 2009/5/14 sudhir kumar <smalikphy@gmail.com>:
>   
>> 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?
>>
>>     
>>>> (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
>>>       
> Did you send the patch on the mailing list? Can you please point me to
> it. In my knowledge -redir tcp *:* breaks with -net tap. If running an
> external dhcp/dns server is the solution then the patch should go in.
> Thanks in advance!!
>   
Thanks for pointing out this problem. The redirections indeed breaks the
tap networking. TAP patch could be seen at
http://marc.info/?l=kvm&m=124221382604554&w=2. The redirections also
leads the problems of getting the ip address of a user mode nic. So
maybe we could make the tap/user to be an exclusive option.
>>> 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.
>>     
>>>       
>>
>> --
>> Sudhir Kumar
>>
>>     
>
>
>
>