[Libvirt-cim] Re: Test Run Summary (Mar 03 2009): XenFV on Red Hat Enterprise Linux Server release 5.3 (Tikanga) with Pegasus

[Deepti B Kalakeri]

Kaitlin Rupert wrote:
>>>>> VirtualSystemMigrationService - 05_migratable_host_errs.py: FAIL
>>>> Passed on manual run.
>>>>
>>>>> VirtualSystemSettingDataComponent - 02_reverse.py: FAIL
>>>>> VirtualSystemSettingDataComponent - 03_vssdc_fwd_errs.py: FAIL
>>>>> VirtualSystemSettingDataComponent - 04_vssdc_rev_errs.py: FAIL
>>>> Passed on manual run.
>>>
>>> For the items that pass on a manual run, any idea why they fail in 
>>> bulk run?
>> I would need to see if NetworkPort - 02_np_gi_errors.py fails on bulk 
>> run again. This is the first time it has failed.
>> But for the following tests I suspect the migration tests the reason.
>>
>> VirtualSystemMigrationService - 05_migratable_host_errs.py: FAIL
>> VirtualSystemSettingDataComponent - 02_reverse.py: FAIL
>> VirtualSystemSettingDataComponent - 03_vssdc_fwd_errs.py: FAIL
>> VirtualSystemSettingDataComponent - 04_vssdc_rev_errs.py: FAIL
>>
>> Most of the times the dom_migrate domain that is created on the host 
>> does not get cleaned.
>> Since all the tc uses the same images, the consecutive tests fails 
>> when they try to create a new guest.
>> The problem is seen only with Xen/XenFV and that too with the Rhel, 
>> if you remember we used to face the same problem with Rhel5.2 as well.
>> It takes lot of virsh destroy commands to actually destroy the guest 
>> created by the migration tc.
>> Sometimes I need to restart the xend to see the refreshed list of 
>> domains on the host.
>>
>
> What about something like the following:
>
> 1) Have the migration tests make a copy of the image and use that copy 
> to define the guest.
>
> 2) Before the test completes, the copied image could be duplicated.
>
> This way, the guests created for the migration test wouldn't be 
> utilizing the image that the other tests need.

I will take a look at this.

-- 
Thanks and Regards,
Deepti B. Kalakeri
IBM Linux Technology Center
deeptik at linux.vnet.ibm.com