12:36 p.m.
The association provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration. This
patch set tries to fix it. Please review. Thanks.
Based on:
- #2 Fix (again) VSMCaps and ElementCap
- Remove devid-style InstanceID support from ELEC and EC
12:36 p.m.
New subject: [PATCH 1 of 9] EAFP: Provider registered per subclass
# HG changeset patch
# User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
# Date 1196683313 -3600
# Node ID 6dbbe2c148a7cc2ba74ffc9e3ddcf7acdc30042c
# Parent 8140438a647cd53017d79b7036702fc053fe9e9c
EAFP: Provider registered per subclass
The provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration.
wbemain -ac CIM_ElementAllocatedFromPool
'http://localhost/root/virt:KVM_Memory.DeviceID="qemu1/mem",CreationClassName="KVM_Memory",SystemName="qemu1",SystemCreationClassName=""'
localhost:5988/root/virt:KVM_MemoryPool.InstanceID="MemoryPool/0"
localhost:5988/root/virt:KVM_MemoryPool.InstanceID="MemoryPool/0"
Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
diff -r 8140438a647c -r 6dbbe2c148a7 schema/ElementAllocatedFromPool.registration
--- a/schema/ElementAllocatedFromPool.registration Fri Nov 30 17:21:33 2007 -0800
+++ b/schema/ElementAllocatedFromPool.registration Mon Dec 03 13:01:53 2007 +0100
@@ -1,4 +1,4 @@
# Copyright IBM Corp. 2007
# Classname Namespace ProviderName ProviderModule ProviderTypes
-Xen_ElementAllocatedFromPool root/virt Xen_ElementAllocatedFromPoolProvider
Virt_ElementAllocatedFromPool association
-KVM_ElementAllocatedFromPool root/virt KVM_ElementAllocatedFromPoolProvider
Virt_ElementAllocatedFromPool association
+Xen_ElementAllocatedFromPool root/virt Virt_ElementAllocatedFromPoolProvider
Virt_ElementAllocatedFromPool association
+KVM_ElementAllocatedFromPool root/virt Virt_ElementAllocatedFromPoolProvider
Virt_ElementAllocatedFromPool association
diff -r 8140438a647c -r 6dbbe2c148a7 src/Virt_ElementAllocatedFromPool.c
--- a/src/Virt_ElementAllocatedFromPool.c Fri Nov 30 17:21:33 2007 -0800
+++ b/src/Virt_ElementAllocatedFromPool.c Mon Dec 03 13:01:53 2007 +0100
@@ -326,8 +326,7 @@ static struct std_assoc *handlers[] = {
NULL
};
-STDA_AssocMIStub(, Xen_ElementAllocatedFromPoolProvider, _BROKER, libvirt_cim_init(),
handlers);
-STDA_AssocMIStub(, KVM_ElementAllocatedFromPoolProvider, _BROKER, libvirt_cim_init(),
handlers);
+STDA_AssocMIStub(, Virt_ElementAllocatedFromPoolProvider, _BROKER, libvirt_cim_init(),
handlers);
/*
* Local Variables:
12:36 p.m.
New subject: [PATCH 2 of 9] EC: Provider registered per subclass
# HG changeset patch
# User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
# Date 1196683550 -3600
# Node ID 97209a4aec46e659a9134dc28ac19c2f43b51c7c
# Parent 6dbbe2c148a7cc2ba74ffc9e3ddcf7acdc30042c
EC: Provider registered per subclass
The provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration.
Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
diff -r 6dbbe2c148a7 -r 97209a4aec46 schema/ElementCapabilities.registration
--- a/schema/ElementCapabilities.registration Mon Dec 03 13:01:53 2007 +0100
+++ b/schema/ElementCapabilities.registration Mon Dec 03 13:05:50 2007 +0100
@@ -1,4 +1,4 @@
# Copyright IBM Corp. 2007
# Classname Namespace ProviderName ProviderModule ProviderTypes
-Xen_ElementCapabilities root/virt Xen_ElementCapabilitiesProvider
Virt_ElementCapabilities association
-KVM_ElementCapabilities root/virt KVM_ElementCapabilitiesProvider
Virt_ElementCapabilities association
+Xen_ElementCapabilities root/virt Virt_ElementCapabilitiesProvider
Virt_ElementCapabilities association
+KVM_ElementCapabilities root/virt Virt_ElementCapabilitiesProvider
Virt_ElementCapabilities association
diff -r 6dbbe2c148a7 -r 97209a4aec46 src/Virt_ElementCapabilities.c
--- a/src/Virt_ElementCapabilities.c Mon Dec 03 13:01:53 2007 +0100
+++ b/src/Virt_ElementCapabilities.c Mon Dec 03 13:05:50 2007 +0100
@@ -359,8 +359,7 @@ struct std_assoc *assoc_handlers[] = {
NULL
};
-STDA_AssocMIStub(, Xen_ElementCapabilitiesProvider, _BROKER, libvirt_cim_init(),
assoc_handlers);
-STDA_AssocMIStub(, KVM_ElementCapabilitiesProvider, _BROKER, libvirt_cim_init(),
assoc_handlers);
+STDA_AssocMIStub(, Virt_ElementCapabilitiesProvider, _BROKER, libvirt_cim_init(),
assoc_handlers);
/*
* Local Variables:
* mode: C
12:37 p.m.
New subject: [PATCH 3 of 9] ESD: Provider registered per subclass
# HG changeset patch
# User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
# Date 1196683916 -3600
# Node ID 7c6276f57a7423a8c9a88fd48a3b4b7180948fd1
# Parent 97209a4aec46e659a9134dc28ac19c2f43b51c7c
ESD: Provider registered per subclass
The provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration.
Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
diff -r 97209a4aec46 -r 7c6276f57a74 schema/ElementSettingData.registration
--- a/schema/ElementSettingData.registration Mon Dec 03 13:05:50 2007 +0100
+++ b/schema/ElementSettingData.registration Mon Dec 03 13:11:56 2007 +0100
@@ -1,4 +1,4 @@
# Copyright IBM Corp. 2007
-# Classname Namespace ProviderName ProviderModule ProviderTypes ...
-Xen_ElementSettingData root/virt Xen_ElementSettingDataProvider Virt_ElementSettingData
association
-KVM_ElementSettingData root/virt KVM_ElementSettingDataProvider Virt_ElementSettingData
association
+# Classname Namespace ProviderName ProviderModule ProviderTypes
+Xen_ElementSettingData root/virt Virt_ElementSettingDataProvider Virt_ElementSettingData
association
+KVM_ElementSettingData root/virt Virt_ElementSettingDataProvider Virt_ElementSettingData
association
diff -r 97209a4aec46 -r 7c6276f57a74 src/Virt_ElementSettingData.c
--- a/src/Virt_ElementSettingData.c Mon Dec 03 13:05:50 2007 +0100
+++ b/src/Virt_ElementSettingData.c Mon Dec 03 13:11:56 2007 +0100
@@ -227,8 +227,7 @@ static struct std_assoc *handlers[] = {
NULL
};
-STDA_AssocMIStub(, Xen_ElementSettingDataProvider, _BROKER, libvirt_cim_init(),
handlers);
-STDA_AssocMIStub(, KVM_ElementSettingDataProvider, _BROKER, libvirt_cim_init(),
handlers);
+STDA_AssocMIStub(, Virt_ElementSettingDataProvider, _BROKER, libvirt_cim_init(),
handlers);
/*
* Local Variables:
12:37 p.m.
New subject: [PATCH 4 of 9] HS: Provider registered per subclass
# HG changeset patch
# User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
# Date 1196685310 -3600
# Node ID 495e8bdd4e1415b253fd64f0527760ad11b75580
# Parent 7c6276f57a7423a8c9a88fd48a3b4b7180948fd1
HS: Provider registered per subclass
The provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration.
Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
diff -r 7c6276f57a74 -r 495e8bdd4e14 schema/HostedService.registration
--- a/schema/HostedService.registration Mon Dec 03 13:11:56 2007 +0100
+++ b/schema/HostedService.registration Mon Dec 03 13:35:10 2007 +0100
@@ -1,4 +1,4 @@
# Copyright IBM Corp. 2007
-# Classname Namespace ProviderName ProviderModule ProviderTypes ...
-Xen_HostedService root/virt Xen_HostedServiceProvider Virt_HostedService association
-KVM_HostedService root/virt KVM_HostedServiceProvider Virt_HostedService association
+# Classname Namespace ProviderName ProviderModule ProviderTypes
+Xen_HostedService root/virt Virt_HostedServiceProvider Virt_HostedService association
+KVM_HostedService root/virt Virt_HostedServiceProvider Virt_HostedService association
diff -r 7c6276f57a74 -r 495e8bdd4e14 src/Virt_HostedService.c
--- a/src/Virt_HostedService.c Mon Dec 03 13:11:56 2007 +0100
+++ b/src/Virt_HostedService.c Mon Dec 03 13:35:10 2007 +0100
@@ -159,8 +159,7 @@ static struct std_assoc *handlers[] = {
NULL
};
-STDA_AssocMIStub(, Xen_HostedServiceProvider, _BROKER, libvirt_cim_init(), handlers);
-STDA_AssocMIStub(, KVM_HostedServiceProvider, _BROKER, libvirt_cim_init(), handlers);
+STDA_AssocMIStub(, Virt_HostedServiceProvider, _BROKER, libvirt_cim_init(), handlers);
/*
* Local Variables:
12:37 p.m.
New subject: [PATCH 5 of 9] RAFP: Provider registered per subclass
# HG changeset patch
# User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
# Date 1196685311 -3600
# Node ID 9fac31df90d1ce6279aff869ad9da51b411223e9
# Parent 495e8bdd4e1415b253fd64f0527760ad11b75580
RAFP: Provider registered per subclass
The provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration.
Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
diff -r 495e8bdd4e14 -r 9fac31df90d1 schema/ResourceAllocationFromPool.registration
--- a/schema/ResourceAllocationFromPool.registration Mon Dec 03 13:35:10 2007 +0100
+++ b/schema/ResourceAllocationFromPool.registration Mon Dec 03 13:35:11 2007 +0100
@@ -1,4 +1,4 @@
# Copyright IBM Corp. 2007
# Classname Namespace ProviderName ProviderModule ProviderTypes
-Xen_ResourceAllocationFromPool root/virt Xen_ResourceAllocationFromPoolProvider
Virt_ResourceAllocationFromPool association
-KVM_ResourceAllocationFromPool root/virt KVM_ResourceAllocationFromPoolProvider
Virt_ResourceAllocationFromPool association
\ No newline at end of file
+Xen_ResourceAllocationFromPool root/virt Virt_ResourceAllocationFromPoolProvider
Virt_ResourceAllocationFromPool association
+KVM_ResourceAllocationFromPool root/virt Virt_ResourceAllocationFromPoolProvider
Virt_ResourceAllocationFromPool association
\ No newline at end of file
diff -r 495e8bdd4e14 -r 9fac31df90d1 src/Virt_ResourceAllocationFromPool.c
--- a/src/Virt_ResourceAllocationFromPool.c Mon Dec 03 13:35:10 2007 +0100
+++ b/src/Virt_ResourceAllocationFromPool.c Mon Dec 03 13:35:11 2007 +0100
@@ -305,8 +305,7 @@ static struct std_assoc *handlers[] = {
NULL
};
-STDA_AssocMIStub(, Xen_ResourceAllocationFromPoolProvider, _BROKER, libvirt_cim_init(),
handlers);
-STDA_AssocMIStub(, KVM_ResourceAllocationFromPoolProvider, _BROKER, libvirt_cim_init(),
handlers);
+STDA_AssocMIStub(, Virt_ResourceAllocationFromPoolProvider, _BROKER, libvirt_cim_init(),
handlers);
/*
* Local Variables:
12:37 p.m.
New subject: [PATCH 6 of 9] SDC: Provider registered per subclass
# HG changeset patch
# User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
# Date 1196685311 -3600
# Node ID 4caca9f23d36235f40a1011be956e3c8d135f77b
# Parent 9fac31df90d1ce6279aff869ad9da51b411223e9
SDC: Provider registered per subclass
The provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration.
Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
diff -r 9fac31df90d1 -r 4caca9f23d36 schema/SettingsDefineCapabilities.registration
--- a/schema/SettingsDefineCapabilities.registration Mon Dec 03 13:35:11 2007 +0100
+++ b/schema/SettingsDefineCapabilities.registration Mon Dec 03 13:35:11 2007 +0100
@@ -1,4 +1,4 @@
# Copyright IBM Corp. 2007
# Classname Namespace ProviderName ProviderModule ProviderTypes
-Xen_SettingsDefineCapabilities root/virt Xen_SettingsDefineCapabilitiesProvider
Virt_SettingsDefineCapabilities association
-KVM_SettingsDefineCapabilities root/virt KVM_SettingsDefineCapabilitiesProvider
Virt_SettingsDefineCapabilities association
+Xen_SettingsDefineCapabilities root/virt Virt_SettingsDefineCapabilitiesProvider
Virt_SettingsDefineCapabilities association
+KVM_SettingsDefineCapabilities root/virt Virt_SettingsDefineCapabilitiesProvider
Virt_SettingsDefineCapabilities association
diff -r 9fac31df90d1 -r 4caca9f23d36 src/Virt_SettingsDefineCapabilities.c
--- a/src/Virt_SettingsDefineCapabilities.c Mon Dec 03 13:35:11 2007 +0100
+++ b/src/Virt_SettingsDefineCapabilities.c Mon Dec 03 13:35:11 2007 +0100
@@ -900,8 +900,7 @@ struct std_assoc *assoc_handlers[] = {
};
-STDA_AssocMIStub(, Xen_SettingsDefineCapabilitiesProvider, _BROKER, libvirt_cim_init(),
assoc_handlers);
-STDA_AssocMIStub(, KVM_SettingsDefineCapabilitiesProvider, _BROKER, libvirt_cim_init(),
assoc_handlers);
+STDA_AssocMIStub(, Virt_SettingsDefineCapabilitiesProvider, _BROKER, libvirt_cim_init(),
assoc_handlers);
/*
* Local Variables:
12:37 p.m.
New subject: [PATCH 7 of 9] SDS: Provider registered per subclass
# HG changeset patch
# User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
# Date 1196685312 -3600
# Node ID 909704b38ca4c9bfcb1121924053f26818d8316b
# Parent 4caca9f23d36235f40a1011be956e3c8d135f77b
SDS: Provider registered per subclass
The provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration.
Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
diff -r 4caca9f23d36 -r 909704b38ca4 schema/SettingsDefineState.registration
--- a/schema/SettingsDefineState.registration Mon Dec 03 13:35:11 2007 +0100
+++ b/schema/SettingsDefineState.registration Mon Dec 03 13:35:12 2007 +0100
@@ -1,4 +1,4 @@
# Copyright IBM Corp. 2007
# Classname Namespace ProviderName ProviderModule ProviderTypes
-Xen_SettingsDefineState root/virt Xen_SettingsDefineStateProvider
Virt_SettingsDefineState association
-KVM_SettingsDefineState root/virt KVM_SettingsDefineStateProvider
Virt_SettingsDefineState association
+Xen_SettingsDefineState root/virt Virt_SettingsDefineStateProvider
Virt_SettingsDefineState association
+KVM_SettingsDefineState root/virt Virt_SettingsDefineStateProvider
Virt_SettingsDefineState association
diff -r 4caca9f23d36 -r 909704b38ca4 src/Virt_SettingsDefineState.c
--- a/src/Virt_SettingsDefineState.c Mon Dec 03 13:35:11 2007 +0100
+++ b/src/Virt_SettingsDefineState.c Mon Dec 03 13:35:12 2007 +0100
@@ -399,8 +399,7 @@ static struct std_assoc *handlers[] = {
NULL
};
-STDA_AssocMIStub(, Xen_SettingsDefineStateProvider, _BROKER, libvirt_cim_init(),
handlers);
-STDA_AssocMIStub(, KVM_SettingsDefineStateProvider, _BROKER, libvirt_cim_init(),
handlers);
+STDA_AssocMIStub(, Virt_SettingsDefineStateProvider, _BROKER, libvirt_cim_init(),
handlers);
/*
* Local Variables:
12:37 p.m.
New subject: [PATCH 8 of 9] SD: Provider registered per subclass
# HG changeset patch
# User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
# Date 1196685313 -3600
# Node ID c6de8c296f561df41811ca04c2ea992b729cfea3
# Parent 909704b38ca4c9bfcb1121924053f26818d8316b
SD: Provider registered per subclass
The provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration.
Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
diff -r 909704b38ca4 -r c6de8c296f56 schema/SystemDevice.registration
--- a/schema/SystemDevice.registration Mon Dec 03 13:35:12 2007 +0100
+++ b/schema/SystemDevice.registration Mon Dec 03 13:35:13 2007 +0100
@@ -1,4 +1,4 @@
# Copyright IBM Corp. 2007
# Classname Namespace ProviderName ProviderModule ProviderTypes
-Xen_SystemDevice root/virt Xen_SystemDeviceProvider Virt_SystemDevice association
-KVM_SystemDevice root/virt KVM_SystemDeviceProvider Virt_SystemDevice association
+Xen_SystemDevice root/virt Virt_SystemDeviceProvider Virt_SystemDevice association
+KVM_SystemDevice root/virt Virt_SystemDeviceProvider Virt_SystemDevice association
diff -r 909704b38ca4 -r c6de8c296f56 src/Virt_SystemDevice.c
--- a/src/Virt_SystemDevice.c Mon Dec 03 13:35:12 2007 +0100
+++ b/src/Virt_SystemDevice.c Mon Dec 03 13:35:13 2007 +0100
@@ -288,8 +288,7 @@ static struct std_assoc *assoc_handlers[
NULL
};
-STDA_AssocMIStub(, Xen_SystemDeviceProvider, _BROKER, libvirt_cim_init(),
assoc_handlers);
-STDA_AssocMIStub(, KVM_SystemDeviceProvider, _BROKER, libvirt_cim_init(),
assoc_handlers);
+STDA_AssocMIStub(, Virt_SystemDeviceProvider, _BROKER, libvirt_cim_init(),
assoc_handlers);
/*
* Local Variables:
5:33 p.m.
New subject: [PATCH 8 of 9] SD: Provider registered per subclass
HE> # HG changeset patch
HE> # User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
HE> # Date 1196685313 -3600
HE> # Node ID c6de8c296f561df41811ca04c2ea992b729cfea3
HE> # Parent 909704b38ca4c9bfcb1121924053f26818d8316b
HE> SD: Provider registered per subclass
Some of these providers still have ASSOC_MATCH() in them which, when
combined with your s/Xen_/Virt_/ change to the provider name, causes
them to always return no instances. I first noticed this with
SystemDevice, but there are others in your set that need to have those
calls removed.
When I remove them, this patch seems fine to me.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
12:37 p.m.
New subject: [PATCH 9 of 9] VSSDC: Provider registered per subclass
# HG changeset patch
# User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
# Date 1196685314 -3600
# Node ID cd9afb53c5e76783d891d7bda74d1e642cf6701e
# Parent c6de8c296f561df41811ca04c2ea992b729cfea3
VSSDC: Provider registered per subclass
The provider was registered for each subclass with a different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration.
Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
diff -r c6de8c296f56 -r cd9afb53c5e7 schema/VSSDComponent.registration
--- a/schema/VSSDComponent.registration Mon Dec 03 13:35:13 2007 +0100
+++ b/schema/VSSDComponent.registration Mon Dec 03 13:35:14 2007 +0100
@@ -1,4 +1,4 @@
# Copyright IBM Corp. 2007
# Classname Namespace ProviderName ProviderModule ProviderTypes
-Xen_VirtualSystemSettingDataComponent root/virt Xen_VSSDComponentProvider
Virt_VSSDComponent association
-KVM_VirtualSystemSettingDataComponent root/virt KVM_VSSDComponentProvider
Virt_VSSDComponent association
+Xen_VirtualSystemSettingDataComponent root/virt Virt_VSSDComponentProvider
Virt_VSSDComponent association
+KVM_VirtualSystemSettingDataComponent root/virt Virt_VSSDComponentProvider
Virt_VSSDComponent association
diff -r c6de8c296f56 -r cd9afb53c5e7 src/Virt_VSSDComponent.c
--- a/src/Virt_VSSDComponent.c Mon Dec 03 13:35:13 2007 +0100
+++ b/src/Virt_VSSDComponent.c Mon Dec 03 13:35:14 2007 +0100
@@ -230,8 +230,7 @@ static struct std_assoc *handlers[] = {
NULL
};
-STDA_AssocMIStub(, Xen_VSSDComponentProvider, _BROKER, libvirt_cim_init(), handlers);
-STDA_AssocMIStub(, KVM_VSSDComponentProvider, _BROKER, libvirt_cim_init(), handlers);
+STDA_AssocMIStub(, Virt_VSSDComponentProvider, _BROKER, libvirt_cim_init(), handlers);
/*
* Local Variables:
4:45 p.m.
HE> The association provider was registered for each subclass with a
HE> different name. That caused duplicated instances as the same
HE> provider gets called twice, but has no chance to figure out for
HE> which registration.
It does, actually, if you use ASSOC_MATCH(). That was the little hack
we used to prevent duplicate entries while enumerating a CIM_Foo class
while we were not using connect_by_classname(). However, I think that
using the classname connection to prevent duplicates is better. Some
care may be required in associations that do not have to connect to
libvirt.
HE> This patch set tries to fix it. Please review. Thanks.
I tested EAFP and it works for me. I'll move on to test the rest, but
feedback from others would be good.
Thanks!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
5:58 p.m.
Heidi Eckhart wrote:
The association provider was registered for each subclass with a
different
name. That caused duplicated instances as the same provider gets
called twice, but has no chance to figure out for which registration. This
patch set tries to fix it. Please review. Thanks.
Based on:
- #2 Fix (again) VSMCaps and ElementCap
- Remove devid-style InstanceID support from ELEC and EC
Applying these patches didn't fix the dups for me (btw, thanks for
finding the dups!). I think the Virt_ provider still gets called twice.
--
Kaitlin Rupert
IBM Linux Technology Center
karupert(a)us.ibm.com
6:06 p.m.
KR> Applying these patches didn't fix the dups for me (btw, thanks for
KR> finding the dups!). I think the Virt_ provider still gets called
KR> twice.
Yeah, with more testing, I still get dups as well. Changing back to a
unified provider name doesn't change the fact that the CIMOM still
calls the provider once per registered class. The unified case
prevents us from having a key to filter on too.
My previous statement about connect_by_classname() is invalid too,
because we use the ref for connecting, which will be, for example,
Xen_Foo in both cases (for the KVM instance and the Xen instance of
the provider's registration).
So, I think the bottom line is: We still need ASSOC_MATCH() and it is
the proper way to fix this problem for the associations that we
currently have without it.
Right?
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
7:13 p.m.
Dan Smith wrote:
KR> Applying these patches didn't fix the dups for me (btw,
thanks for
KR> finding the dups!). I think the Virt_ provider still gets called
KR> twice.
Yeah, with more testing, I still get dups as well. Changing back to a
unified provider name doesn't change the fact that the CIMOM still
calls the provider once per registered class. The unified case
prevents us from having a key to filter on too.
My previous statement about connect_by_classname() is invalid too,
because we use the ref for connecting, which will be, for example,
Xen_Foo in both cases (for the KVM instance and the Xen instance of
the provider's registration).
So, I think the bottom line is: We still need ASSOC_MATCH() and it is
the proper way to fix this problem for the associations that we
currently have without it.
Right?
Right.. ASSOC_MATCH() solves this problem. There might be another
solution, but I'm not sure of one at the moment.
--
Kaitlin Rupert
IBM Linux Technology Center
karupert(a)us.ibm.com
1:33 p.m.
Kaitlin Rupert wrote:
Dan Smith wrote:
> KR> Applying these patches didn't fix the dups for me (btw, thanks for
> KR> finding the dups!). I think the Virt_ provider still gets called
> KR> twice.
>
> Yeah, with more testing, I still get dups as well. Changing back to a
> unified provider name doesn't change the fact that the CIMOM still
> calls the provider once per registered class.
Yes, for Pegasus, but not for
sfcb - sfcb calls the association provider
only once, with the client's assocClass (e.g. CIM_SystemDevice), while
Pegasus manipulates assocClass to fit the subclass' association name
(Xen_SystemDevice and KVM_SystemDevice) and calls the provider for each
subclass.
> The unified case
> prevents us from having a key to filter on too.
Therefore I added
match_hypervisor_prefix() function, which compares the
given ref prefix with the client requested assocClass and resultClass
prefix.
>
> My previous statement about connect_by_classname() is invalid too,
> because we use the ref for connecting, which will be, for example,
> Xen_Foo in both cases (for the KVM instance and the Xen instance of
> the provider's registration).
Yes, we can not use the ref to figure out for
which association the
provider was called. :(
>
> So, I think the bottom line is: We still need ASSOC_MATCH() and it is
> the proper way to fix this problem for the associations that we
> currently have without it.
>
> Right?
>
Right.. ASSOC_MATCH() solves this problem. There might be another
solution, but I'm not sure of one at the moment.
Right. And I also know, that the ASSOC_MATCH solution was developed to
deal with Pegasus' special behavior to handle association requests. As
mentioned above, sfcb is calling the Virt_ providers only once. We could
now start a discussion which solution is the right one, but as we will
not be the ones who decide on this, I would like to implement a
solutions, that also makes use of the optimized sfcb behavior, where the
provider is called only once.
My suggestion now is, to replace ASSOC_MATCH by
match_hypervisor_prefix() and register Virt_ providers instead of
Xen_/KVM_ for each subclass. The advantage can not be seen with Pegasus,
as Pegasus will still call the provider for each subclass with the
manipulated assocClass. But for sfcb we get rid of an unnecessary
provider call. What do you think ?
But you both are right - the patch set is buggy and needs to be fixed in
regard to ASSOC_MATCH. Thanks for making me aware of it. Will try to
send out a fix as soon as possible.
--
Regards
Heidi Eckhart
Software Engineer
Linux Technology Center - Open Hypervisor
heidieck(a)linux.vnet.ibm.com
**************************************************
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
4:36 p.m.
HE> Yes, for Pegasus, but not for sfcb - sfcb calls the association
HE> provider only once, with the client's assocClass
HE> (e.g. CIM_SystemDevice), while Pegasus manipulates assocClass to
HE> fit the subclass' association name (Xen_SystemDevice and
HE> KVM_SystemDevice) and calls the provider for each subclass.
Ah, okay. Hmm, that's unfortunate that they behave so differently.
So, if you resolve the association with an assocClass of CIM_Foo on
sfcb, the provider handler actually sees CIM_Foo as the assocClass,
per my testing just now. So we need to make sure that we don't use
the assocClass (or resultClass) as the target of a
connect_by_classname(). Might be obvious, but I just wanted to make
it explicit.
HE> Therefore I added match_hypervisor_prefix() function, which
HE> compares the given ref prefix with the client requested assocClass
HE> and resultClass prefix.
Okay, looking at that now, it makes more sense. I was confusing
match_hypervisor_prefix() with match_pn_to_cn().
HE> Right. And I also know, that the ASSOC_MATCH solution was developed to
HE> deal with Pegasus' special behavior to handle association requests.
Well, I didn't know it was special to Pegasus at the time :)
I thought we were seeing the same behavior out of sfcb as well.
HE> As mentioned above, sfcb is calling the Virt_ providers only
HE> once. We could now start a discussion which solution is the right
HE> one, but as we will not be the ones who decide on this,
Personally, Pegasus' behavior makes more logical sense to me, but the
sfcb case does seem more efficient.
HE> I would like to implement a solutions, that also makes use of the
HE> optimized sfcb behavior, where the provider is called only once.
Agreed.
HE> My suggestion now is, to replace ASSOC_MATCH by
HE> match_hypervisor_prefix() and register Virt_ providers instead of
HE> Xen_/KVM_ for each subclass. The advantage can not be seen with
HE> Pegasus, as Pegasus will still call the provider for each subclass
HE> with the manipulated assocClass. But for sfcb we get rid of an
HE> unnecessary provider call. What do you think ?
Yes, and it also eliminates the need to add an additional registration
for each prefix we support, which is a good thing.
Thanks Heidi!
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
4:53 p.m.
Dan Smith wrote:
HE> Yes, for Pegasus, but not for sfcb - sfcb calls the
association
HE> provider only once, with the client's assocClass
HE> (e.g. CIM_SystemDevice), while Pegasus manipulates assocClass to
HE> fit the subclass' association name (Xen_SystemDevice and
HE> KVM_SystemDevice) and calls the provider for each subclass.
Ah, okay. Hmm, that's unfortunate that they behave so differently.
So, if you resolve the association with an assocClass of CIM_Foo on
sfcb, the provider handler actually sees CIM_Foo as the assocClass,
per my testing just now. So we need to make sure that we don't use
the assocClass (or resultClass) as the target of a
connect_by_classname(). Might be obvious, but I just wanted to make
it explicit.
Oh, both of these points are interesting - I didn't realize sfcb behaves
differently (I've never used it). Thanks for bringing up this issue
Heidi =)
--
Kaitlin Rupert
IBM Linux Technology Center
karupert(a)us.ibm.com
6131
days inactive
6132
days old
17 comments
3 participants
participants (3)
-
Dan Smith -
Heidi Eckhart -
Kaitlin Rupert