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. Doing a : wbemcli ein http://root:password@localhost:5988/root/virt:KVM_VirtualSystemManagementSer... 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