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