| |
|
 |
|
 |
|
|
|
| |
|
|
xen-cim
Re: [Xen-cim] CIM_RecordedState and CIM_RecordedSetting questions
Szymanski, Lukasz K wrote:
I used the latest docs and mofs from the DMTF as a basis of my questions:
1)
The definitions of CIM_RecordedSetting are different in the System and
Resource docs. In the RVP it has elements CurrentSetting and
RecordedSetting; in the SVP it has ActiveSetting and RecordedSetting.
So which should I believe?
I think this is just a cleanup issue. Wish I would have added this to
my comments on the recent SVP ballot :-). ActiveSetting == CurrentSetting.
2)
Looking at the mofs we see
CIM_RecordedSetting:
CIM_ResourceAllocationSettingData REF CurrentSetting
CIM_ResourceAllocationSettingData REF RecordedSetting
CIM_RecordedState:
CIM_ResourceAllocationSettingData REF RecordedSetting
CIM_ResourceAllocationSettingData REF ActiveSetting
So what is the difference between ActiveSetting and CurrentSetting?
And also, CIM_RecordedState.mof matches the definition of
CIM_RecordedSetting in the SVP.
I would ignore the CIM_RecordedState.mof. It resides in the Archives
folder and is only there for "historical reference".
3)
From the Resource Virtualization Profile:
P. 17: Recorded State in diagram 7-1 (looks like an association)
P. 20: Recorded State in diagram 7-2 (looks like an association),
RecordedSetting is mentioned in the diagram description below it,
RecordedState is not. Why?
There is no mention of RecordedState association in the CIM Element
Overview, but there is for RecordedSetting. Why?
FYI, Resource Virtualization Profile is now Resource Allocation Profile
and the pages / figures you mentioned are different. But to answer the
question, I would say mentally replace RecordedState with
RecordedSetting wherever you see it in either profile. There is some
mixing of RecordedState and RecordedSetting in the latest Resource
Allocation Profile under ballot and I will comment on this, i.e. replace
all instances of RecordedState with RecordedSetting.
4)
From the Resource Virtualization Profile:
P. 32
11.7 CIM_ResourceAllocationSettingData
...
This setting data instance represents the recorded state of the
resource. Implementations may choose to use one instance to reflect
both recorded and current settings and point both references within
CIM_RecordedSetting association on this instance..
...
Is this the way we want to go?
For the time I would say yes. Eventually though we would want to
support different recorded and current settings for resources. Changing
current settings (and thus have recorded and current settings differ) is
probably not an immediate goal with Xen. As Gareth has pointed out,
even ballooning domUs is non-deterministic so probably not something we
should shoot for immediately. However it does make sense to support
changing recorded settings (again resulting in different recorded /
current settings), which would be applied the next time the domU is
activated.
5)
Looking at the ElementSettingData mof I find an element called
IsCurrent and one called IsActive which would make one think that
ElementSettingData somehow differentiates between RecordedState and
RecordedSetting (see mof descriptions above). This, BTW, is out of
sync with the SVP which does not have an IsActive element. Why is that?
Again, RecordedState == RecordedSetting. Also I would suspect that the
IsActive property of CIM_ElementSettingData.mof will be removed since it
is not referenced in any of the current profile documents. If a setting
is current, then IsCurrent should be set to 1 "Is Current". If setting
is recorded, then IsCurrent would be set to 2 "Is Not Current". The
IsActive property is redundant. The IsDefault property is used by
Allocation Capabilities Profile.
Hope this provides some clarification.
Jim
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
|
|
|
| |
|
Home