Kaitlin Rupert wrote:
I hit a minor issue with Pegasus. After a postinstall, I see the following:
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.
Yes, I'm aware of this issue. The reason for this message is following. To register a provider for Pegasus it is necessary to create the following instances (that are configured by the <classname>.registration file) in Pegasus' root/PG_InterOp namespace. This is the content of the ElementConformsToProfile.registration file: Xen_ElementConformsToProfile root/virt Virt_ElementConformsToProfile Virt_ElementConformsToProfile association Xen_ElementConformsToProfile root/interop Virt_ElementConformsToProfile Virt_ElementConformsToProfile association KVM_ElementConformsToProfile root/virt Virt_ElementConformsToProfile Virt_ElementConformsToProfile association KVM_ElementConformsToProfile root/interop Virt_ElementConformsToProfile Virt_ElementConformsToProfile association that is translated to: * one instance of PG_ProviderModule registering the provider's module name as defined by STDA_AssocMIStub() ... Virt_ElementConformsToProfile * one instance of PG_Provider registering the name of the provider library ... Virt_ElementConformsToProfile * one instance of PG_ProviderCapabilities per classname registration - one instance of PG_ProviderCapabilities ... Xen_ElementConformsToProfile-1 (root/virt) - one instance of PG_ProviderCapabilities ... Xen_ElementConformsToProfile-2 (root/interop) - one instance of PG_ProviderCapabilities ... KVM_ElementConformsToProfile-3 (root/virt) - one instance of PG_ProviderCapabilities ... KVM_ElementConformsToProfile-4 (root/interop) This is done each time when running provider_register - in our case twice ... root/virt and root/interop (see Makefile.am postinstall step). The provider_register script does now skip all PG_ProviderCapabilities instances, who's namespace is not the same as the one given by the caller of provider_register. But with the current setup of provider_register it would cause a disproportional effort to make the second run (root/interop) aware of that the first run (root/virt) has already registered PG_ProviderModule and PG_Provider. As the second registration try does only cause the warnings above but no corruption, I decided to live with them (for now). FYI ... sfcb's registration does not run into this issue :). -- Regards Heidi Eckhart Software Engineer IBM Linux Technology Center - Open Hypervisor