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
19 messages in com.xensource.lists.xen-cimRE: [Xen-cim] Requirements and priori...
.gif, .gif, .gif