|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-cim] Re: Various implementation questions
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
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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |