|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-cim] Requirements and priorities for SLES10 SP1
Hi Gareth,
sure, the metric implementation is available in open source anyhow so this
doc can be shared as well:
(See attached file: ExistingXenMetrics.pdf)
Short comments on current status:
- memory metrics: if /proc/refaults ever makes it into the mainline kernel,
this could really help us understand optimal memory size of a virtual
server
- CPU metrics somehow assume processor frequency is constant. If it's not,
we currently don't have any efficient way to deal with that, so metrics may
be misleading. If we'd externalize # instructions executed and related
metrics, this would be much more precise and higher value, however we can't
get such metrics from user mode
- I/O: I'd guess it's most important for now to get dom0 properly
instrumentation (e.g. based on existing SBLIM providers). But of course we
can discuss what else we can do here in addition. Ideally, the hypervisor
would capture using/delay statistics to show which virtual servers are
competing for the same resources. Would have the advantage that we'd get
the same metrics, with similar instrumentation, for ethernet network,
infiniband, iSCSI, System z FICON, ... whereas SMI-S and DMTF currently
need different models for various kinds of I/O
Best regards/ Mit freundlichen Gruessen
Oliver Benke
eServer Systems Management Technology
email: benke@xxxxxxxxxx phone: +49-7031-16-3306
IBM Germany Lab, Schoenaicher Str. 220, 71032 Boeblingen
Gareth S Bestor
<bestorga@xxxxxxx
com> To
Sent by: Ewan Mellor <ewan@xxxxxxxxxxxxx>,
xen-cim-bounces@l Oliver Benke/Germany/IBM@IBMDE
ists.xensource.co cc
m Jim Fehlig <jfehlig@xxxxxxxxxx>,
xen-cim@xxxxxxxxxxxxxxxxxxx
Subject
21.12.2006 20:47 Re: [Xen-cim] Requirements and
priorities for SLES10 SP1
The SBLIM Data Gatherer package - including some preliminary DMTF Metric
model implementation of Xen metrics - is located at
http://sourceforge.net/project/showfiles.php?group_id=128809&package_id=144595
Oliver, do you have a (non IBM-Confidential) doc describing in more detail
these metrics that we can share?
- Gareth
(Embedded image moved to file: pic28380.gif)Inactive hide details for Ewan
Mellor <ewan@xxxxxxxxxxxxx>Ewan Mellor <ewan@xxxxxxxxxxxxx>
Ewan
Mellor
<ewan@x
ensourc (Embedded image moved to file:
e.com> pic20988.gif)
Sent To
by: (Embedded image moved to file:
xen-cim pic20091.gif)
-bounce Gareth S
s@lists Bestor/Beaverton/IBM@IBMUS
.xensou (Embedded image moved to file:
rce.com pic32439.gif)
cc
(Embedded image moved to file:
12/19/0 pic13874.gif)
6 03:53 Jim Fehlig <jfehlig@xxxxxxxxxx>,
PM xen-cim@xxxxxxxxxxxxxxxxxxx,
xen-cim-bounces@xxxxxxxxxxxxxxxxx
om
(Embedded image moved to file:
pic10517.gif)
Subject
(Embedded image moved to file:
pic26836.gif)
Re: [Xen-cim] Requirements and
priorities for SLES10 SP1
(Embedded image moved to file:
pic28805.gif)
(Embedded image moved to
file: pic14666.gif)
On Fri, Dec 15, 2006 at 02:58:21PM -0800, Gareth S. Bestor wrote:
> >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.
Do you have any notes on this that I could see? I'd like to get the
stats gathering into Xend and the Xen-API soon, so I would certainly
appreciate it if you've got a requirements list for me.
> > ...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.
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
(Embedded image moved to file: pic08928.gif)
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
Attachment:
ExistingXenMetrics.pdf Attachment:
pic28380.gif Attachment:
pic20988.gif Attachment:
pic20091.gif Attachment:
pic32439.gif Attachment:
pic13874.gif Attachment:
pic10517.gif Attachment:
pic26836.gif Attachment:
pic28805.gif Attachment:
pic14666.gif Attachment:
pic08928.gif _______________________________________________ Xen-cim mailing list Xen-cim@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-cim
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |
