Re: [Xen-cim] CIM_RecordedState and CIM_RecordedSetting questions

[Gareth S Bestor <bestor@xxxxxxxxxx>]

>> 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.

This is precisely the purpose of having separate 'recorded' and 'curent'("active') settings for *everything*; in some implementations it is possible to change the runtime params (eg balloon memory) but you still dont want to clobber what the VM was initially configured with. But as Jim points out, there are not too many meaningful DomU config params right now where this is useful. I'm not sure what the best approach is to handle the current non-deterministic memory ballooning that Xen offers today - it certainly qualifies as a useful feature to expose to a user, but the fact that it may or may not ever actually balloon (non-deterministic), and hard to precisely identify when the inband OS releases the memory, its an awkward thing to expose. I might suggest we wait till we get some in-band OS memory usage instrumented, and so have a better idea of what's actually going on with the DomU's memorry usage.

- Gareth

Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186

Jim Fehlig <jfehlig@xxxxxxxxxx>

Jim Fehlig <jfehlig@xxxxxxxxxx>
Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx

06/20/06 03:21 PM

To	"Szymanski, Lukasz K" <Lukasz.Szymanski@xxxxxxxxxx>
cc	xen-cim@xxxxxxxxxxxxxxxxxxx
Subject	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

_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim