xen-cim
Re: [Xen-cim] Requirements and priorities for SLES10 SP1
Inline...
On 12/21/06 11:35 AM, "Gareth S Bestor" <bestorga@xxxxxxxxxx> wrote:
>...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.
This I don’t understand. If there’s something missing, it needs to be added. This is presumably an iterative refinement...
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.
This is worrying.
We, Xen-CIM, still have to learn to crawl (on the box) before we can run! :-)
IMO, the baseline requirement should be that the CIM providers can run both locally and remotely.
Simon
- 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
Simon
--
Simon Crosby
XenSource m: +1 415 819 1965
2300 Geng Road # 250 o: +1 650 798 5936
Palo Alto, CA 94303 skype: simoncrosby
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
|
|
|