[Libvirt-cim] [RESEND PATCH 0/3] libvirt-cim: Fix provider registration

Daniel Hansel daniel.hansel at linux.vnet.ibm.com
Thu Nov 14 10:28:16 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 12.11.2013 18:34, John Ferlan wrote:
> 
>>> 
>>> I'm much of an expert in these matters - in fact pre-novice would summarize my experience with RPM files :-)
>>> 
>>> Things seem reasonable; however, I'm in a bit of a quandary now as I cannot get my libvirt-cim environment to work in order to test. This past Friday I did do a yum update and since that time
>>> I cannot seem to get the libvirt-cim provider and cimserver to talk - quite frustrating.
>>> 
>>> I was actually hoping to spend this week reviewing and testing libvirt-cim patches...  Now I'm just trying to figure out why two best friends won't speak to each other any more :-)
>> Hi John,
>> 
>> could describe your libvirt-cim environment a bit more detailed (e.g. OS version, installed package versions of libvirt and libvirt-cim, cimserver, etc.)?
>> 
>> Maybe we could figure out the error together.
>> 
> 
> 
> 
> Sure - I am running f19 on a lenovo t530 - it's my work supplied laptop
> 
> I generally use the top of the libvirt and libvirt-cim tree, although those didn't change when this issue was discovered.
> 
> Prior to 10/30/13, I'm not sure which version of tog-pegasus* was installed; however, as of that day the following was installed:
> 
> Oct 30 08:00:41 Updated: 2:tog-pegasus-libs-2.12.1-8.fc19.x86_64 Oct 30 08:01:08 Updated: 2:tog-pegasus-2.12.1-8.fc19.x86_64 Oct 30 08:01:39 Updated: 2:tog-pegasus-devel-2.12.1-8.fc19.x86_64
> 
> 
> a 'cimprovider -l' does not return any KVM_ modules a sure sign of things not working...
> 
> In order to help dig, I enabled debugging:
> 
> cimconfig -s traceLevel=4 -c cimconfig -s traceComponents=ALL -c
> 
> Looking at the cimserver.trc file I find these (sorry about the formatting my auto line wrap is on):
> 
> 1384276573s-184895us: Repository [7944:139824043710528:FileBasedStore.cpp:631]: Namespace: root#PG_InterOp ignored -- subdirectories are not correctly formed 1384276573s-186825us: L10N 
> [7944:139824043710528:MessageLoader.cpp:418]: Message ID = Common.InternalException.CANNOT_OPEN_DIRECTORY 1384276573s-187030us: Repository [7944:139824043710528:FileBasedStore.cpp:1347]: 
> Namespace: root#PG_InterOp ignored -- subdirectories are not correctly formed 1384276573s-194463us: ProviderManager [7944:139824043710528:ProviderRegistrationManager.cpp:1934]: nameSpace = 
> root/interop; className = PG_ProviderModule
> 
> I think you get the picture though - there's something about PG_InterOp which is different.  Since it's one of those things that 2.12.1-8 release notes discusses as changing in 2.12.1-4, I have a
> feeling whatever it is the libvirt-cim.spec does in order to "link up" as a provider, does not work in the same way any more.
> 
Hi John,

after investigating in this problem we have seen that with tog-pegasus version 2.12.1-5 the namespace for base classes was changed from root/PG_Interop to root/interop.
tog-pegasus can be build using an option that changes this namespace to one of these 2 namespaces.
As far as we could see RedHat is using this option (and the new namespace) in their build of tog-pegasus.

The cim providers that should be installed have to use the correct namespace to find the right classes.
This would lead to an incompatibility of cim providers AND clients.

Therefore the pegasus community does NOT recommend the change to the new namespace until a backwards compatible way is implemented in tog-pegasus.

Kind regards,
Daniel

> 
> Doing a :
> 
> wbemcli ein http://root:password@localhost:5988/root/virt:KVM_VirtualSystemManagementService
> 
> gets:
> 
> 1384277180s-587013us: ProviderManager [9934:140222156466240:ProviderRegistrationManager.cpp:395]: nameSpace = root/virt; className = KVM_VirtualSystemManagementService; className = 
> root/virtkvm_virtualsystemmanagementserviceinstance 1384277180s-587020us: ProviderManager [9934:140222156466240:ProviderRegistrationManager.cpp:406]:  Provider capability has not been registered
>  yet. 1384277180s-587028us: Dispatcher [9934:140222156466240:CIMOperationRequestDispatcher.cpp:1465]: Provider for KVM_VirtualSystemManagementService not found.
> 
> But no output from the wbemcli command.
> 
> I did try "going backwards" and installing an older rpm, but was not successful.  So I borrowed another RHEL6.5 system and am testing over there today.
> 
> 
> John
> 
> 

- -- 

Mit freundlichen Grüßen / Kind regards
Daniel Hansel

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShKXAAAoJEJszBMQcau4WLEEP/juXbDAah/EcsHahjBUT5PN6
oNnzVK0PJrbM5JAFszc7gp4N5gyxV50IVIexD8s3pqOvob7BlBYgIRuw3uzW9jcP
UxMwsYz4StYPpGws4IjamisIHIeAwt3JfQapGdi5VJ0YJDRfsMacGdQbB8pmYbWT
aiNQeQu6lu3i+KEBMbWzp9N210jMQwJJrG55I3VmxlbJsZpbHvTdRXXp4waQqArK
sIHZgSRV0WY+pdG6QQuQ/I5lJQVjLuVUXd9wu/rX19Ii9S6U4Gequ+44/TIacsRV
dAJEGpCrpuydl+RJn24RXACH5FwrnpKoVsdp23KpY+faq+Z1ICCLAUcpzVvgeUjl
YB7I9HTrmvpQ16X6tDzPiNP7sZD03sZgnT5yqat8ZN9tb9Uju8ZVKLJtcSQfZ1LA
M1qTwlwFtUSY/qFkBD07s5TLEDPfLucJWrHg5sNOUs1gB9nHW9rv9eUuIwSl114h
doWwUhj1TtyfYu/SQFIjm7Y63UYr7i7+g7QlzL/jvKMpI0kUgZfU+m7bhSVFcVm0
DGZ14u2GXOQKam2YnsSb8DiUiOSO0y7qmNCh6bYhEuhxussdB8Ls7xdtN6lKF+Ej
hAW3LRIdO3QgAj0vIOswFg9K46+EMvSIJglhah0poG1+xZ13zNxLTM3EOUYWS3Wm
vzspVoxGLLagzog0ywy/
=TF+o
-----END PGP SIGNATURE-----




More information about the Libvirt-cim mailing list