Hi Mike, Tks for the reply...
On Tue, Apr 24, 2012 at 10:47 AM, Mike Burns <[email protected]> wrote: > Hi Geoff, > > On Tue, 2012-04-24 at 07:49 +1000, Geoff O'Callaghan wrote: > > Hi All > > > > > > I notice that ovirt-node 2.3.0 had CIM handling added via > > bz 753215 / http://gerrit.ovirt.org/#change,2480 . I thought i'd > > give it a test. Alas, I can't get it to work. > > > Yes, I failed to communicate that there were problems with the cim > stuff. > > The overall goal was to expose libvirt-cim schemas, not all cim schemas, > though that could be a next step. > > [snip] > > Given the above output, you obviously know far more about cim than I do. > From what I've learned, there is an incompatibility between sblim-sfcb > and libvirt-cim in Fedora 16. We'll look closer as we move to F17 as > the base install. > Nah, i'm a CIM newbie, i've used it a little bit with ESX but nothing too serious. I was just trying to get my head around it with ovirt. > > > I tried this on F16 and centos6 - same result, so either i'm doing > > something terribly wrong or there is a bug in the upstream. > > > > > > Note: I tried the > > > > > > wbemcli ecn -noverify against an esxi box and got the expected result, > > so I can also confirm it's not a problem with my wbemcli client :) > > > > I've tested the same code on a RHEVH-6 machine and can connect correctly > to the libvirt-cim interface. > > > > Just before I submitted this I found > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=809090 > > https://bugzilla.redhat.com/show_bug.cgi?id=809093 > > > > > > I didn't find a bz against ovirt-node as well, should I raise one and > xref with the above info and F16/17 bz's ? > > You can, but there's not much we can do until libvirt-cim and sblim-sfcb > start working in Fedora. Part of the problem is that there apparently > isn't much demand cim working in upstream. > > We're also looking for people that actually know something about cim to > help with developing and testing cim. > > Further exploring tonight shows that the libvirt-cim package is not correctly registering the mof files. ie. If you do a sfcbrepos -h you will see something like : [root@kvm1 admin]# sfcbrepos -h usage: /usr/bin/sfcbrepos [-h] [-f] [-i] [-b backendopt] [-c cimschemadir] [-s stagingdir] [-r registrationdir] -h display help message -f force repository creation -i do not migrate instances from previous repository (default=do migrate) -X create repository in non-native format as specifed by argument -s specify staging directory [/var/lib/sfcb/stage] -r specify repository directory [/var/lib/sfcb/registration] -c specify directory containing CIM Schema MOFs [/usr/share/mof/cim-current] -t create tiny class repository by omitting inheritance information -z compress repository with gzip If you look in /var/lib/sfcb/registration you will see a directory structure ./root ./root/cimv2 ./root/interop ./root/interop/qualifiers ./root/interop/sfcb_registeredprofile ./root/interop/sfcb_indicationservicecapabilities ./root/interop/classSchemas ./root/interop/sfcb_registeredprofile.idx ./root/interop/sfcb_indicationservicecapabilities.idx ./root/interop/qualifiers.idx This implies that the cimv2 class is there, but empty, which agrees with the test result. It also shows that there should be an root/interop class that works.... so testing that... $ wbemcli ecn -noverify https://cim:[email protected]/root/interop 10.100.0.3:5989/root/interop:CIM_IndicationFilter 10.100.0.3:5989/root/interop:CIM_Service 10.100.0.3:5989/root/interop:CIM_RegisteredSubProfile 10.100.0.3:5989/root/interop:CIM_WBEMService 10.100.0.3:5989/root/interop:CIM_AbstractIndicationSubscription 10.100.0.3:5989/root/interop:CIM_IndicationService 10.100.0.3:5989/root/interop:CIM_ListenerDestinationCIMXML 10.100.0.3:5989/root/interop:CIM_IndicationHandler ..... etc Doing an instance query against one of the above... $ wbemcli ein -noverify https://cim:[email protected]/root/interop:CIM_Service 10.100.0.3:5989/root/interop:CIM_ObjectManager.CreationClassName= "CIM_ObjectManager",SystemCreationClassName="CIM_ComputerSystem",SystemName=" kvm1.example.com",Name="sfcb:NO-UUID-FILE-kvm1.example.com" So the CIM broker appears to be working, it's just that the mof's aren't registered properly - assuming i'm using the term mof correctly :-) A rpm -ql libvirt-cim reveals a bunch of stuff, specifically stuff like : /usr/share/libvirt-cim/AllocationCapabilities.mof /usr/share/libvirt-cim/AllocationCapabilities.registration /usr/share/libvirt-cim/AppliedFilterList.mof ... /usr/share/libvirt-cim/cim_schema_2.21.0Experimental-MOFs.zip /usr/share/libvirt-cim/cimv2.21.0-cimv2_mof /usr/share/libvirt-cim/cimv2.21.0-interop_mof /usr/share/libvirt-cim/install_base_schema.sh /usr/share/libvirt-cim/provider-register.sh The provider-register.sh is the important bit, it should be passed parms to get it to configure for sfcb - the problem is in this script as it's not doing what it should be doing - manually running it doesn't work and you get errors like : # ./provider-register.sh -v -t sfcb -r KVMRedirectionSAP.registration -m KVMRedirectionSAP.mof Staging provider registration. cp: cannot stat `/var/tmp/KVMRedirectionSAP.reg': No such file or directory Error: could not copy registration files Failed to stage provider registration. However, if I try using the same script from another package that supplies mof's - eg sblim-cmpi-base then it mostly works.... (ie replace the libvirt-cim script with the one from sblim-cmpi-base) # ./provider-register.sh -v -t sfcb -r KVMRedirectionSAP.registration -m KVMRedirectionSAP.mof Registering class Xen_KVMRedirectionSAP Registering class KVM_KVMRedirectionSAP Registering class LXC_KVMRedirectionSAP Staging provider registration. Shutting down sfcb. Stopping sblim-sfcb (via systemctl): [ OK ] Timed out waiting for sfcb shutdown... Please stop sfcb manually and rebuild the repository using sfcbrepos. [root@ovirt-f16 libvirt-cim]# service sfcb stop Redirecting to /bin/systemctl stop sfcb.service [root@ovirt-f16 libvirt-cim]# sfcbrepos Setting up sfcb Repository, Class, and Provider Registration Your old repository and registration data will be deleted (static instances will be saved) Do you want to proceed? (type yes to continue) yes and testing (note: I did this on a F16 system that exhibits the same problem rather than on the node itself). $ wbemcli ecn -noverify https://root:[email protected]/root/cimv2|egrep KVM 192.168.1.63:5989/root/cimv2:KVM_KVMRedirectionSAP 192.168.1.63:5989/root/cimv2:Xen_KVMRedirectionSAP 192.168.1.63:5989/root/cimv2:CIM_KVMRedirectionSAP 192.168.1.63:5989/root/cimv2:LXC_KVMRedirectionSAP That's as far as I got as I need to do some other stuff, but the above may help and I may get some more time tomorrow to see if I can figure what the intention of the libvirt-cim rpm really is. Tks Geoff
_______________________________________________ node-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/node-devel
