Re: [Xen-cim] Requirements and priorities for SLES10 SP1

[Gareth S Bestor <bestorga@xxxxxxxxxx>]

>...Having the CIM providers go around the API would be bad for portability and
>for supporting various use cases in which CIM is required, but not within
>each instance of Dom0.

To clarify, I expect there will be some mgmt needs for the Xen-CIM mgmt interfaces that are not Xen/hypervisor specific and therefore likely not to be exposed thru Xen-API. In particular, the DMTF SV model does have some CIM_Dependency hooks into host system resource data, certain metrics about specific virtual device utilization (eg DomU memory) may require going inband, etc. So its not so much going around the API, but rather the info needed is probably outside the scope of a pure Xen-API. For now I believe everything we need for the CIM classes we've implemented is pretty well covered (in principle) by Xen-API, and if anything comes up missing we'll certainly look into whether it can be/is appropraite to add to Xen-API. But I cannot categorically state that 100% of the (generic) virtual system managabiity functions eventually expressed on the CIM interface will either [a] be wholly a subset of the Xen-API functionality, or [b] otherwise have their own remote interface.

So it may be the case that a remoted CIM mgmt interface to a Xen box (or other hypervisor platforms for that matter) may have <100% CIM manageability richness of a local CIM mgmt interface. Again, this will probably come down to how much of Linux itself is remotely (non-CIM) manageable as opposed to anything lacking in Xen-API per se. In some cases needed raw Linux data/mgmt control knobs may have remote interfaces too, but I've certainly not driven down thru *all* the DMTF SV classes proposed - and likely to come down the line - to understand whether *everything* can be offloaded and managed remotely.

We, Xen-CIM, still have to learn to crawl (on the box) before we can run! :-)

- Gareth  
 
Simon Crosby <simon@xxxxxxxxxxxxx>

Simon Crosby <simon@xxxxxxxxxxxxx>
Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx

12/19/06 06:54 PM

To	Ewan Mellor <ewan@xxxxxxxxxxxxx>, Gareth S Bestor/Beaverton/IBM@IBMUS
cc	Jim Fehlig <jfehlig@xxxxxxxxxx>, xen-cim@xxxxxxxxxxxxxxxxxxx, xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
Subject	Re: [Xen-cim] Requirements and priorities for SLES10 SP1

On 12/19/06 3:53 PM, "Ewan Mellor" <ewan@xxxxxxxxxxxxx> wrote:

> On Fri, Dec 15, 2006 at 02:58:21PM -0800, Gareth S. Bestor wrote:
> 

>>> ...I am not sure if we can do it all from CIM (since we are only going
>> to go through the XenAPI).
>> 
>> Doing everything thru XenAPI is certianly cleaner (and makes life easier
>> for us) but its not an absolutely requirement... We can certainly ask to
>> broaden the scope of XenAPIs coverage, but it may still be the case that
>> the CIM providers will have to exploit other APIs/OS mgmt interfaces to do
>> things.
> 
> Yes, you certainly _can_ ask for Xen-API to be extended where necessary.
> What do you need?  Don't forget, Xen-API is going to be the _only_ off-box API
> preserved over the long term.  It's in everybody's interests if the CIM
> providers can do everything that they need through that API.  Please,
> feel free to ask if there are bits that are missing.
> 
> Ewan.

Moreover, I believe we agreed that running the CIM providers off the managed
host on some other system (ie not in Dom0), is a use case that we need to
support - this for example would be useful for embedded implementations.
Having the CIM providers go around the API would be bad for portability and
for supporting various use cases in which CIM is required, but not within
each instance of Dom0.


Simon

-- 


_______________________________________________
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