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/
Home Products Support Community News


Re: [Xen-API] Xen Management API draft

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-API] Xen Management API draft
From: Daniel Veillard <veillard@xxxxxxxxxx>
Date: Sat, 24 Jun 2006 19:22:20 -0400
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 24 Jun 2006 16:22:38 -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: veillard@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,

definitely ? because that's really where it should be done, or just because
you don't want any direct hypervisor calls ? A direct hypervisor call
don't even force a dom0 context switch to implement, in contrast the RPC
is, very very expensive.

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

  I don't think trying to add more feature into xend is really a good
way to solve the real problem, in my opinion the hyprvisor calls for
getting performance data should be considered at least as standard as
any xend RPC api. I understand that we should avoid them for any call
with side effect, but for monitoring, I don't see how you will be able
to offer a flexible alternative. You don't need very high rate polling
to just eat all CPU when going though RPC and Xend as our experiments
have shown. In libvirt if I don't use the hypervisor calls a few refresh
per second of the state of the hypervisor takes a very significant fraction
of the overall CPU (for example if you use the fedora virtualization applet
for monitoring as an non-root user).


Daniel Veillard      | Red Hat http://redhat.com/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

xen-api mailing list