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: Daniel Veillard <veillard@xxxxxxxxxx>
Subject: Re: [Xen-API] Xen Management API draft
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Sun, 25 Jun 2006 00:37:23 +0100
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 24 Jun 2006 16:37:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060624232220.GS1330@xxxxxxxxxx>
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> <20060624232220.GS1330@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Sat, Jun 24, 2006 at 07:22:20PM -0400, Daniel Veillard wrote:

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

Your answer here goes right to the heart of what you want libvirt to be.  We
know that we will need a C binding to the XML-RPC, so that people can make RPC
calls from their C programs.  The CIM guys need this, for example.  I thought
that libvirt was trying to be this binding, and that the hypercalls in there
at the moment were just a stop-gap.

Above though, you seem to be talking of libvirt as something different to that
-- it's a library that sits on the managed node, that uses Xend when it needs
to, but that is happy to bypass Xend when it can, for performance.
Architecturally, that's a very different beast.  Is that how you see libvirt
developing?  Do you intend to continue to bypass Xend in the long-term, where
performance can be gained from doing so?  That's an interesting idea.


xen-api mailing list