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

[Gareth S Bestor <bestorga@xxxxxxxxxx>]

In terms of the minimal set of required
CIM classes prescribed by the DMTF System Virtualization model, I expect
all can be implemented via the new Xen-API, and hence can be run on a remote
proxy. However, the DMTF SV profile also has some loose dependencies/interactions
with other DMTF CIM profiles, eg base server profile (for host resource
mgmt), SMIS block device profiles (for managing host disk storage), network
profiles, power management profiles, etc. So for a CIM client to have access
to the *full* richness of managing a virtualization-capable host and its
various resources - some of which will be virtualized/allocated to VMs
- the mgmt app will at times need to interact with non-System Virtualization
classes/CIM providers, some of which may or may not be 'remoteable'. As
a specific example, Xen allows dedicated assignment of PCI slots to VMs,
so at some point we'll be adding to Xen-CIM the respective CIM classes
for PCI slot 'pools', RASDs, and pass-thru virtual PCI slots assignment
. However, a mgmt app will probably be more interested in knowing and assigning
what is *attached* to each PCI slot to a VM, eg a DVD drive. To perform
such an informed assignment the mgmt app will need to explore various host-side
system resource CIM classes; ie exploit host information not necessarily
exposed via the Xen-API.

There is also nothing in CIM itself
that dictates that all providers for managing a host and its resource must
be able to run remotely from a proxy, that is purely a function of whether
the underlying system resource mgmt api's have a lower-level remote interface.
Indeed, in a lot of cases where there is no current remote mgmt interface
for managing a host resource/service, CIM itself can be considered a means
to support (standardized) remote management!

The ability today to expose a full suite
of proxy CIM providers to enable everything we may want to do when managing
a Xen host is basically only as feasible as it is today to fully manage
a Xen host without ever resorting to telnet/ssh. Whilst the Xen-API may
enable everything we need in terms of assigning the primitive host resources
to a VM and managing the VM's lifecycle, an mgmt app will likely want to
do more in terms of host resource discovery, host (and inband guest) resource
monitoring, etc which I would probably consider outside the scope of a
pure Xen-API, and which may not today have their own remote mgmt interface.

Hope that helps clarify. Like I said
earlier, bypassing Xen-API is to be avoided at all costs, and for our Xen-CIM
providers themselves there is no foreseeable reason to do so. But other
CIM classes (for host mgmt) which may be prerequisites for full mgmt support
may not be runnable for a proxy.

- Gareth

Simon Crosby <simon@xxxxxxxxxxxxx>

12/22/2006 12:18 AM

To	Gareth S Bestor/Poughkeepsie/IBM@IBMUS
cc	Ewan Mellor <ewan@xxxxxxxxxxxxx>, Gareth S Bestor/Beaverton/IBM@IBMUS, Jim Fehlig <jfehlig@xxxxxxxxxx>, <xen-cim@xxxxxxxxxxxxxxxxxxx>
Subject	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