Build error on with the librvirt-cim provider
Hi, I notice the following errors for postinstall with the new libvirt-cim providers: 1) device_parsing.c: In function '_change_device': device_parsing.c:943: warning: assignment from incompatible pointer type device_parsing.c:945: warning: assignment from incompatible pointer type make[3]: *** [device_parsing.lo] Error 1 make[3]: Leaving directory `/usr/src/deepti/libvirt-cim/libxkutil' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/deepti/libvirt-cim/libxkutil' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/deepti/libvirt-cim' make: *** [all] Error 2 I continue to see the above errors, and I use --diable-werror to supress this. When can we expect this to be resolved? 2) Registering providers with active cimserver Warning: CIMMethod MigrateVirtualSystemToHost already exists for CIMClass CIM_VirtualSystemMigrationService Parsing error: parse error: Error adding an instance: CIM_ERR_FAILED: A provider is already registered for the specified capability. make: *** [postinstall] Error 250 The above error according to me was beacuse there were two enteries with the MigrateVirtualSystemToHost() function name in the mof file. uint32 MigrateVirtualSystemToHost( [In] CIM_ComputerSystem REF ComputerSystem, [In] string DestinationHost, [In, EmbeddedInstance("CIM_SettingData")] string MigrationSettingData, [In, EmbeddedInstance("CIM_VirtualSystemSettingData")] string NewSystemSettingData, [In, EmbeddedInstance("CIM_ResourceAllocationSettingData")] string NewResourceSettingData[], [Out] CIM_ConcreteJob REF Job ); uint32 MigrateVirtualSystemToHost( [In] CIM_ComputerSystem REF ComputerSystem, [In] CIM_System REF DestinationSystem, [In, EmbeddedInstance("CIM_SettingData")] string MigrationSettingData, [In, EmbeddedInstance("CIM_VirtualSystemSettingData")] string NewSystemSettingData, [In, EmbeddedInstance("CIM_ResourceAllocationSettingData")] string NewResourceSettingData[], [Out] CIM_ConcreteJob REF Job ); I verified this with the Virt_VSMigrationService.c file and I thought that the second MigrateVirtualSystemToHost() function should have been MigrateVirtualSystemToSystem(), and after making the changes the above error was resolved. Apart from this I see one last error at the end of postinstall. I used to see this error long back, which was not seen for sometime. I have not checked how I can fix this. Registering providers with active cimserver Parsing error: parse error: Error adding an instance: CIM_ERR_FAILED: A provider is already registered for the specified capability. make: *** [postinstall] Error 250 One more thing, Since the postinstall was not successful the RegisteredProfile , ElementConformsToProfile and ReferencedProfile were not registered and hence lots of tc failed.I registered these manually and they worked fine. Thanks and Regards, Deepti.
DK> device_parsing.c: In function '_change_device': DK> device_parsing.c:943: warning: assignment from incompatible pointer DK> type DK> device_parsing.c:945: warning: assignment from incompatible pointer DK> type DK> make[3]: *** [device_parsing.lo] Error 1 DK> make[3]: Leaving directory `/usr/src/deepti/libvirt-cim/libxkutil' DK> make[2]: *** [all-recursive] Error 1 DK> make[2]: Leaving directory `/usr/src/deepti/libvirt-cim/libxkutil' DK> make[1]: *** [all-recursive] Error 1 DK> make[1]: Leaving directory `/usr/src/deepti/libvirt-cim' DK> make: *** [all] Error 2 DK> I continue to see the above errors, and I use --diable-werror to DK> supress this. When can we expect this to be resolved? You're on RHEL5.2ish, right? The libvirt-0.3.3 in RHEL has been patched to fix a bug, but the version number was not updated. In the code, we alter our expected definition of a libvirt function based on the version number to avoid this warning. However, this will always fail on RHEL 5.2. Just use --disable-werror when working on systems with a patched libvirt-0.3.3. DK> The above error according to me was beacuse there were two enteries DK> with the MigrateVirtualSystemToHost() function name in the mof file. Ah yes, I noticed this the other day, but forgot to fix it. This is definitely a problem, but I'm confused about why it is fatal for you. I get a warning, but the registration process proceeds. DK> Registering providers with active cimserver Parsing error: parse DK> error: Error adding an instance: CIM_ERR_FAILED: A provider is DK> already registered for the specified capability. make: *** DK> [postinstall] Error 250 This may be caused by some cruft in your repository. You might try nuking our namespace and trying again. To do that, do something like: rm -Rf /usr/lib64/Pegasus/repository/root\#virt -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
DK> device_parsing.c: In function '_change_device': DK> device_parsing.c:943: warning: assignment from incompatible pointer DK> type DK> device_parsing.c:945: warning: assignment from incompatible pointer DK> type DK> make[3]: *** [device_parsing.lo] Error 1 DK> make[3]: Leaving directory `/usr/src/deepti/libvirt-cim/libxkutil' DK> make[2]: *** [all-recursive] Error 1 DK> make[2]: Leaving directory `/usr/src/deepti/libvirt-cim/libxkutil' DK> make[1]: *** [all-recursive] Error 1 DK> make[1]: Leaving directory `/usr/src/deepti/libvirt-cim' DK> make: *** [all] Error 2
DK> I continue to see the above errors, and I use --diable-werror to DK> supress this. When can we expect this to be resolved?
You're on RHEL5.2ish, right? The libvirt-0.3.3 in RHEL has been patched to fix a bug, but the version number was not updated. In the code, we alter our expected definition of a libvirt function based on the version number to avoid this warning. However, this will always fail on RHEL 5.2. Just use --disable-werror when working on systems with a patched libvirt-0.3.3.
Yes, this error is from the RHEL5.2. Since I did not install the libvirt on the machine which I am using for testing, how do we verify if its patched libvirt ?
DK> The above error according to me was beacuse there were two enteries DK> with the MigrateVirtualSystemToHost() function name in the mof file.
Ah yes, I noticed this the other day, but forgot to fix it. This is definitely a problem, but I'm confused about why it is fatal for you. I get a warning, but the registration process proceeds.
What steps do you use for registration ?
DK> Registering providers with active cimserver Parsing error: parse DK> error: Error adding an instance: CIM_ERR_FAILED: A provider is DK> already registered for the specified capability. make: *** DK> [postinstall] Error 250
This may be caused by some cruft in your repository. You might try nuking our namespace and trying again. To do that, do something like:
rm -Rf /usr/lib64/Pegasus/repository/root\#virt
I will not be able to give the result of this immediately as the RHEL machine which I use is down. Thanks and Regards, Deepti.
------------------------------------------------------------------------
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
DK> Yes, this error is from the RHEL5.2. Since I did not install the DK> libvirt on the machine which I am using for testing, how do we DK> verify if its patched libvirt ? If it's libvirt-0.3.3 and you get the error that you're getting, then you're using a patched libvirt. We also know that RHEL5.x has the patch. The workaround is to continue to specify --disable-werror on the configure line. DK> I will not be able to give the result of this immediately as the DK> RHEL machine which I use is down. My recent two schema patches should resolve this issue for you. Thanks! -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
DK> Yes, this error is from the RHEL5.2. Since I did not install the DK> libvirt on the machine which I am using for testing, how do we DK> verify if its patched libvirt ?
If it's libvirt-0.3.3 and you get the error that you're getting, then you're using a patched libvirt. We also know that RHEL5.x has the patch. The workaround is to continue to specify --disable-werror on the configure line.
DK> I will not be able to give the result of this immediately as the DK> RHEL machine which I use is down.
My recent two schema patches should resolve this issue for you.
I did not find any postinstall errors on RHEL today, except for some warnings below. Processing provider modules: Virt_ElementConformsToProfile Virt_ReferencedProfile Virt_RegisteredProfile Registering providers with active cimserver Warning: the instance already exists. In this implementation, that means it cannot be changed. Warning: the instance already exists. In this implementation, that means it cannot be changed. Can we get the name of the instance as part of log messages, which it tried to reinstall ? Or the above message meant, Virt_ElementConformsToProfile Virt_ReferencedProfile Virt_RegisteredProfile were already registered ?? Thanks and Regards, Deepti.
Thanks!
------------------------------------------------------------------------
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
I did not find any postinstall errors on RHEL today, except for some warnings below.
Processing provider modules: Virt_ElementConformsToProfile Virt_ReferencedProfile Virt_RegisteredProfile Registering providers with active cimserver Warning: the instance already exists. In this implementation, that means it cannot be changed. Warning: the instance already exists. In this implementation, that means it cannot be changed.
Can we get the name of the instance as part of log messages, which it tried to reinstall ? Or the above message meant, Virt_ElementConformsToProfile Virt_ReferencedProfile Virt_RegisteredProfile were already registered ??
The ECTP provider is causing this problem. Since it's a cross-namespace provider, we have to register the provider in both the virt and interop namespaces. So, when Pegasus goes to register it in the interop namespace, it recognizes that it's already been registered previously (to the virt namespace). It seems to me that this is a limitation of the CIMOM, since there's not really a way to register the provider with both namespaces simultaneously. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
participants (3)
-
Dan Smith -
Deepti B Kalakeri -
Kaitlin Rupert