Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-api

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.

Ewan.

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