[Libvirt-cim] KVM test report on Fedora 9 (4/30)
Kaitlin Rupert
kaitlin at linux.vnet.ibm.com
Fri May 2 15:04:38 UTC 2008
> wbemain -ac KVM_ElementConformsToProfile
'http://u:p@host:5988/root/virt:KVM_ComputerSystem.CreationClassName="KVM_ComputerSystem",Name="domgst"'
> I dont see the KVM_ElementConformsToProfile.CIM_ElementConformsToProfile
> registered in the root#virt namespace on F9 machine with rpm
> libvirt-cim, while the same is present in both the root#interop and
> root#virt namespace on F9 machine with latest libvirt-cim sources.
This might be a bug in the rpm install - I'll take a look.
> I tried copying the provider manually to the root#virt namespace and
> restarted the cimserver, but I did not get any results even after that.
> I dont know if this is proper way of registering the mof files in the
> namespace.
To register a mof file, you can do the following:
sudo cimmofl -uc -aEV -R$PEGASUS_REPO -n /root/virt <mof file>
Where PEGASUS_REPO is the location of your Pegasus repository (probably
PEGASUS_REPO=/var/lib/Pegasus).
However, the rpm should be doing this for you.
> Although, the above wbemcli gives me expected o/p on the
> F9 with rpm when the query includes the root/interop namespace,
> While on the F9 with latest source I get o/p for query with root/virt
> namespace.
ECTP is a cross-namespace provider. For our implementation, that means
the ECTP mof is registered to both root/interop and root/virt. The
provider is also registered to both name spaces.
You said said the following query works for you with the F9 rpm:
wbemain -ac KVM_ElementConformsToProfile
'http://localhost:5988/root/interop:KVM_ComputerSystem.CreationClassName="KVM_ComputerSystem",Name="domgst"'
That's a bug which been fixed in recent sources. You should see the
following:
*
* wbemain: Cim: (6) CIM_ERR_NOT_FOUND: CIM_ERR_NOT_FOUND:
KVM_ComputerSystem.CreationClassName="KVM_ComputerSystem",Name="domgst"
*
This query is asking for the associators for this reference in the
interop namespace. However, that instance doesn't exist in the interop
namespace - it should only exist in the virt namespace. To verify, you
can try the following query - it should also fail:
wbemcli gi
'http://localhost:5988/root/interop:KVM_ComputerSystem.CreationClassName="KVM_ComputerSystem",Name="domgst"'
> Could you please tell me the namespace and ECTP provider registration
> details.
Take a look at the ECTP registration file
(schema/ElementConformsToProfile.registration) and compare this with the
registration file for ComputerSystem (schema/ComputerSystem.registration).
>>
>>> ElementSettingData - 03_esd_assoc_with_rasd_errs.py: FAIL
>> This one passed in individual run. The previous ElementConforms.04
>> undefine fix doesn't help here. Might be some other unknown missing
>> undefine.
Is the test failing because it cannot create the guest, or is it due to
some other issue?
>>
>>> NetworkPort - 03_user_netport.py: FAIL
>> 'user' network type.
>> [Known Issue]
>>
>>> ReferencedProfile - 01_verify_refprof.py: FAIL
>> Binary rpm provider gives 2 results on the following query:
>> wbemein http://u:p@host:5988/root/interop:KVM_RegisteredProfile
>> "CIM:DSP1042-SystemVirtualization-1.0.0"
>> "CIM:DSP1057-VirtualSystem-1.0.0a"
>> Same wbemcli command gets 5 results on changeset-533 tree on another
>> system.
>> "CIM:DSP1042-SystemVirtualization-1.0.0"
>> "CIM:DSP1057-VirtualSystem-1.0.0a"
>> "CIM:DSP1059-GenericDeviceResourceVirtualization-1.0.0"
>> "CIM:DSP1045-MemoryResourceVirtualization-1.0.0"
>> "CIM:DSP1081-VirtualSystemMigration-1.0"
> Yes this is correct.
>> This leads to ReferencedProfile's 'ain' query gets only 2 results.
>>
> I did not see the ReferncedProfile query return any results.
> since the ReferencedProfile is not present on the on an rpm libvirt-cim
> based F9 machine and hence the ain query fails without any results.
>>> ReferencedProfile - 02_refprofile_errs.py: FAIL
>> Same as ReferencedProfile.01
>>
> I think the ReferncedProfile was added with the changeset 500 and the
> rpm contains the changes till 393, hence I think the ReferencedProfile
> did not get registered on the machine.
Close - it's changeset 501.
> Should we skip the above test cases for rpm based F9 ?
Yes - that's a good idea. You can check the changeset version, and skip
if it's lower than changeset 501.
Thanks!
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin at linux.vnet.ibm.com
More information about the Libvirt-cim
mailing list