[Libvirt-cim] Re: KVM on Pegasus Test Run Summary for Sep 10 2008 [ Current Source]

[Kaitlin Rupert]

>> =================================================
>> FAIL Test Summary:
>> ComputerSystem - 23_suspend_suspend.py: FAIL
> The above tc passed when run manually.

Do you know what caused the guest to fail to start?  Does the test 
always fail during bulk run?

It sounds like a guest from a previous test isn't being cleaned up 
properly.  This will need to be fixed.

>> =================================================
>> XFAIL Test Summary:
>> ComputerSystem - 32_start_reboot.py: XFAIL
>> ComputerSystem - 33_suspend_reboot.py: XFAIL
>> ResourceAllocationFromPool - 05_RAPF_err.py: XFAIL
> The above RAFP tc is written to verify that RAFP returns appropriate 
> error when a non-existing bridge or networkpool is used in defining a 
> guest.
> But, the tc now XFAIL's because it returns a valid RAFP record.

This should be a failure and not an XFAIL.  There's no bug number 
associated with the failure, so the logic of try_assoc() is incorrectly 
returning an XFAIL.

> This is due to the use of the cim_define() in the test case.
> Before calling the cim_define() we make necessary changes to the XML 
> configuration to reflect the invalid bridge/networkpool name.
> But when we use the cim_define() function we do not have any means where 
> we can use the invalid networkpool name or bridgename.

cim_define() uses the VSSD and various RASD objects that belong to the 
instance of the VirtCIM class that is created.  Instead of using 
modify_net_name(), the invalid network name should be passed in when the 
instance of VirtCIM is initialized.

> Hence the DefineSystem() in the cim_define() goes ahead to define a 
> guest with the valid networkpoolname and RAFP returns a record, which is 
> against the test case.
> I ran the tc for Xen/XenFV and the tc fails there as well.
> Can we revert back to the define() [which used virsh to define the 
> guest], which initially existed in the tc ??

If we use the virsh define, we're testing the virsh define call - the 
provider DefineSystem() is not being tested in this case.  Wherever 
possible, we should be using DefineSystem() so that the provider stack 
is tested.

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