WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

Re: [Xen-API] Xen Management API draft

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-API] Xen Management API draft
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Sun, 25 Jun 2006 15:54:01 +0100
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 25 Jun 2006 07:54:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D4BAB9B@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D4BAB9B@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Sat, Jun 24, 2006 at 09:24:40AM +0100, Ian Pratt wrote:
> > Is it realistic to use XML-RPC for tasks such as resource monitoring?
> > Seems like there should be an optional, lower-latency, lighter-weight
> > mechanism to retrieve things such as host_cpu.utilisation,
> > VBD.IO_bandwidth/incoming_kbs, etc.  
> 
> The whole stats reporting interface certainly needs more thought.
> 
> However, I think it definitely should still use the xml-rpc interface,
> we just need to 'cook' the raw data into something more directly useful
> within xend so that there's no need to do high-rate polling on the API.
> This might involve using something like rrdtool to generate averages
> over different time scales etc.

Cooking the data before making it available to applications is not very
desirable, because it is making an assumption that the way XenD cooks
it is compatible with the format in which monitoring applications need 
the data for processing / analysis. It would be like saying you can only
access Linux kernel performance stats from the averaged SAR records - it
is fine if all you want to do with the data is render graphs, or perform
long term trend analysis, however, if you want to analyse the 'live' data
to do actively monitor system performance you really need access to the
raw data over a low-latency, high performance channel.

It may be that this is impossible over a protocol like XML-RPC, in which 
case we need to consider an alternate channel enabling local applications
to bypass XML-RPC and collect the raw  performance / utilization statitics
without incurring a performance hit. Perhaps this alternate channel is
simply to make direct HyperCalls, which is something libvirt already does
when running as root - calling virDomainGetInfo to collect a domain's
CPU utilization is about 350x faster when dones as a hypercall, compared
to using HTTP/SEXPR[1]

Regards,
Dan.

[1] https://www.redhat.com/archives/libvir-list/2006-April/msg00044.html
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

<Prev in Thread] Current Thread [Next in Thread>