Re: [Xen-API] Xen Management API draft

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

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