[Libvirt-cim] [PATCH] Fix RASD provider unregistration

Dan Smith danms at us.ibm.com
Tue Nov 11 20:35:41 UTC 2008


KR> Since <>_ResourceAllocationSettingData is listed first in the mof,
KR> it doesn't get properly unregistered because
KR> <>_ProcResourceAllocationSettingData (etc) hasn't been
KR> unregistered yet.

Is this sfcb or Pegasus-related?

KR> +# This definition is needed during provider unregistration
KR> +RASD_MOF = schema/ResourceAllocationSettingData.mof
KR> +RASD_REG = schema/ResourceAllocationSettingData.registration

Perhaps we should call this "REREG_MOF" and "REREG_REG" or some such?
We could potentially have this hit us in schema other than the RASDs.

In fact, I think we probably should have had an intermediate class in
most of our schema, where we have a Virt_Foo and inherit the LXC_,
Xen_, KVM_, etc classes from that.  If we move to that in the future,
we'll have this problem everywhere.

Maybe moving the intermediate abstract classes to their own MOF would
be better than re-running the deregistration step?

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com




More information about the Libvirt-cim mailing list