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

[Kaitlin Rupert]

>>>> 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.

-- 
Kaitlin Rupert
IBM Linux Technology Center
kaitlin at linux.vnet.ibm.com