[Xen-cim] Re: Various implementation questions

[Gareth S Bestor <bestor@xxxxxxxxxx>]

We want to try to avoid any dependencies
on specific non-System Virtualization classnames, eg classes for host instrumentation,
and instead rely on the more general CIM_* classnames/profiles. Fortunately,
since all the OMC SMASH providers will be located under the root/smash
namespace, it should be a problem simply referring to, say,  root/smash/CIM_ComputerSystem,
which should pull up any OMC_ComputerSystem subclass.

>Looking into resource pools and how SMASH providers
integrate there, I 
>debated how host resources added to a pool will be persisted.

As an initial pass, where all the relevant
host resources are automatically considered part of the respective resource
pool, there wont be any need to persist anything, since the associations
can be (re)generated on the fly. Once we more fully support pool management
adding/removing host resources then yes, we'll have to persist which resource
are and are not currently in the various pools somewhere. I suppose persiting
the association object itself in the CIMOM repository wold do the trick,
but for some reason this makes me uneasy... I'd need to think thru the
implications and consequences more :-)
 
>BTW, there is a lot off association traversal
in resource pool 
>implementations.

Depends. If the pool provider takes
the 'easy' approach and exploits traversing the CIM associations itself
(ie making the associatio provider do the hard work) and sum everything
up, then yes, there could be a lot of association upcalls to handle. But
depending on how pool membership is persisted, theres nothing to prevent
a smarter pool resource provider extracting the necessary raw data more
efficiently. Really depends on how pool membership is persisted at the
back end.

- Gareth

Jim Fehlig <jfehlig@xxxxxxxxxx>

07/11/2006 02:51 PM

To	Gareth S Bestor/Poughkeepsie/IBM@IBMUS, xen-cim@xxxxxxxxxxxxxxxxxxx
cc
Subject	Various implementation questions

While thinking about integrating SMASH with our Xen
providers, several 
questions came to mind.

Using OMC_<Some Class> directly in mofs (primarily in association
classes) and in the code creates a dependency on OMC project.  Do
we 
really want such a dependency?  We could do some build-time trick
to 
generate mofs and headers with selected host instrumentation, and fall
back to CIM_<Some Class> if nothing is specified and no reasonable
default (e.g. OMC) is found.  The only problem I have with this 
dependency is it is "out of tree".  Users of xen-cim will
have to go yet 
another place (already have to get libvirt) for dependencies.  Using
OMC 
exclusively is certainly the easiest, so if we don't feel this is an 
issue I will just go that route.

Looking into resource pools and how SMASH providers integrate there, I
debated how host resources added to a pool will be persisted.  E.g.
a 
host has 8 processors and management app creates a ProcessorResourcePool
and then adds all host processors.  A ConcreteComponent association
between the pool and each device must be persisted.  One simple solution
is to create an instance of the association and stash it in local CIMOM
instance repository.  Other suggestions?

BTW, there is a lot off association traversal in resource pool 
implementations.  E.g. consider one approach to creating an instance
with just capacity and reservation properties populated:  Traverse
all 
ConcreateComponent associations to get the "real" logical device,
summing to generate capacity.  Then traverse all 
ElementAllocatedFromPool associations to get "virtual" logical
device, 
summing to get reservation.  For the latter, you could optionally
traverse ResourceAllocationFromPool to get RASD for each virtual device,
summing these to generate reservation.

Probably had some other questions but can't think of them now :-).

Jim



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