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

[Gareth S Bestor <bestor@xxxxxxxxxx>]

>I vote for doing only lifecycle indication for now.

BTW - I've already implement some base lifecycle/state indications in Xen_ComputerSystemIndication.c. However, these probably need to be revised to match the latest 'state' properties being used now. Basically, they generate an indication whehter a VM pops into existance, disappears, or changes its 'state' (by checking one of the Xen_CS properties).

FYI - No indications are prescribed by the DMTF SV workgorup yet, so we'll be on the bleeding edge here for a bit longer. :-)


>What kind of metrics are we lookng for here?

Oliver Benke has already implemented a few Xen metrics which he's checked into the SBLIM project Data Gatherer. These are conformant to the DMTF Metrics model, at least as it stands today. In terms of metrics I think the hard prolbem is getting good raw data outa xend and/or the DomU's. Exposing them as CIM object thru the SBLIM Data gatherer will be the easy part.


> ...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.

- Gareth

Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186

"Subrahmanian, Raj" <raj.subrahmanian@xxxxxxxxxx>

"Subrahmanian, Raj" <raj.subrahmanian@xxxxxxxxxx>
Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx

12/15/06 02:01 PM

To	"Jim Fehlig" <jfehlig@xxxxxxxxxx>
cc	xen-cim@xxxxxxxxxxxxxxxxxxx
Subject	RE: [Xen-cim] Requirements and priorities for SLES10 SP1

Jim,
 
> * Indication support. What indications do we want to support?  Just 
> lifecycle events, e.g. VM destroyed, VM deactivated, etc. or 
> indications for device added or device removed as well.
I vote for doing only lifecycle indication for now.

> * Need as much metrics support as possible.  Get it from 
> frontend/backend drivers to avoid going inband.  Probably no 
> way to get 
> descent metrics on memory except inband.  Guest is only one that can 
> give reasonable memory metrics.
What kind of metrics are we lookng for here?
 
> * Support for ResourcePoolConfigurationService on some pool 
> types, e.g. ProcessorPool.This functionality will support for example 
> removing PCPUs from the pool and dedicate to management domain, thus 
> restricting set of PCPUs available for consumption by VMs.  Does xen
support 
> this?  Can we mask PCPUs such that they are not available to VMs?

At the present time, we cannot remove physical processors from the
scheduling for VMs cleanly. We will need to modify the scheduler and
create a new xm command  for that.
There is a way around it. Every time we need some PCPUs taken out, we
will need to create a dummy VM and pin those PCPUs that we want taken
out of the scheduling to it. And destroy that VM when we want to put
them back in the mix. It's not very clean.
 
> * Support for 'driver domains', i.e. PCI pass-thru.
What do we mean by this?
Some of the steps involved in setting up a driver domain don't go
through xend (like 'hiding' the devices from Dom0). I am not sure if we
can do it all from CIM (since we are only going to go through the
XenAPI).

Raj

_______________________________________________
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