Re: [Xen-cim] RecordedSettings questions

[Gareth S Bestor <bestorga@xxxxxxxxxx>]

In regards to the current vs recorded settingdata, see pg 32 of the Resource Allocation Profile. In particular, both the Recorded (aka initial) and Current (aka dynamically modified) SettingDatas for a particular resource are associated to the actual CIM_LogicalDevice (eg Xen_Memory) via an CIM_ElementSettingData subcless. You can distinguish between the two ResourceAllocationSettingData's by the fact that the ElementSettingData assocaition to the *current* ResourceAllocationSettingData will have its IsCurrent property set to true, whereas ny and all other ElementSettingData assoications (to other ResourceAllocationSettingData's, eg the recorded one) it will be false. So to summarize, the distinction between recorded and current SettingData's is made in the *association* (to the LogicialDevice) as opposed to anything in the SettingData itself.

The CIM_RecordedSetting is a slightly different but related beast, which associates all the various ResourceAllocationSettingData's over to the one *recorded* one. This would enable you to hop from one SettingData for some LogicalDevice straight to the one original recorded setting, by following the RecordedSetting assoc rather than having to go up to the LogicalDevice and then down via its ElementSettingData assoications.

But now that I have to try to explin it to someone else, it does seems rather awkward! :-) In particular, there is an emphasis on 'IsCurrent' in the ElementSettingData assoications to distinguish differnet types of Settings from one another, yet we emphasis the 'recorded' setting by having CIM_RecordedSetting between the ResourceAllocationSettingData's themselves... Daniel - whaddayahtink?!

BTW - the IsDefault/IsCurrent/IsActive properties show up in the CIM_ElementSettingData.mof, but not in the CIM_EelementSettingData table in the profile doc (section 10.15). Is this an ommission?

- Gareth

Jim Fehlig <jfehlig@xxxxxxxxxx>

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

07/17/06 01:21 PM

To	"Szymanski, Lukasz K" <Lukasz.Szymanski@xxxxxxxxxx>
cc	xen-cim@xxxxxxxxxxxxxxxxxxx
Subject	Re: [Xen-cim] RecordedSettings questions

Szymanski, Lukasz K wrote:
>
> Hello -
>
> I have been thinking about the whole RecordedSetting approach and came 
> up with the following.  I think there should be 4 additional 
> associations: XenDiskSettingRecordedSetting, 
> XenNetworkPortRecordedSetting, XenMemoryRecordedSetting, and 
> XenComputerSystemRecordedSetting.
>
> This is what I believe is the mof file for XenDiskSettingRecordedSetting
>
> // *******************************************************************
> // Associations
> // *******************************************************************
>
> // ==================================================================
> // Xen_DiskSettingDataRecodedSetting
> // ==================================================================
> [Association,
>  Provider ("cmpi:Xen_DiskSettingDataRecodedSetting"),
>  Description (
>         "A class derived from CIM_RecordedSettings to represent "
>         "the association of a current and/or recorded Xen_Disk setting 
> of "
>         "a virtualized disk device in a Xen domain.
>
> class Xen_DiskSettingDataRecodedSetting : CIM_RecordedSetting
> {
>    [Override("CurrentSetting")]
>    Xen_DiskSettingData REF CurrentSetting;
>
>    [Override("RecordedSetting")]
>    Xen_DiskSettingData REF RecordedSetting;
> };
>

I think the description should be something like "A class derived from 
CIM_RecordedSetting which reflects the relationship between the recorded 
and current settings data for a virtualized disk device in a Xen 
domain."  This class provides the association between recorded and 
current settings data objects.

> I believe the accompanying C file would be similar to the 
> Xen_HostedDisk.c file.
>
> This same pattern could be applied to the other Xen_*RecordedSetting 
> files.
>
> Jim mentioned something on the call about the shim having to be 
> tweaked so it exposes the RecordedSetting stuff.  Can you point me to 
> where that is?
>

xm.c contains the private function get_defined_domain() which returns an 
xm_config structure populated with settings found in the domain conf 
file.  It could be used (perhaps with some refactoring of the code) as a 
source for recorded settings.

> What are your thoughts here?  What else needs to be done?
>

Your approach seems fine.  However, keep in mind that we have not yet 
implemented the actual instantiation of 'recorded' 
CIM_ResourceAllocationSettingData instances.  At this time we are only 
producing the 'current' instances.  So I think the first step would be 
to produce the recorded settings, followed by implementing your 
suggested associations to tie the two together.

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