Re: [Xen-API] Xen Management API draft

[Daniel Veillard <veillard@xxxxxxxxxx>]

On Sun, Jun 25, 2006 at 12:37:23AM +0100, Ewan Mellor wrote:
> 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.

  They are there because for monitoring, just having an RPC based mechanism
could eats 15-20% of the CPU time of an otherwise idle machine when using the 
monitoring applet based on libvirt. 

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

  Well libvirt must be usable for at least minimal monitoring. It uses xend
access by default for all operations except in the case where 1/ the user
can actually use something else (i.e. root currently) and 2/ the operation
is better implemented by other means.
  Architecturally, this is based on some driver plugin definition, and
there is a plugin for xend access, one for xenstore access and one for the
xen hypervisor access. The architecture is expected to remain that way,
for example there is a test plugin now for regression testing too.
  From the API point of view it's the same whatever the mechanism used, 
underneath the library will try to use the best available method. And for
example if xend is dead and the user is root libvirt will first contact
the xenstore if the call can be done that way, and then fallback to the
hypervisor if that's not possible or failed.

   I hope this helps clarify the current design a bit :-)
I don't think a pure C binding over a very specific XML-RPC API would be 
very attractive as a standalone library, maybe I'm wrong.

Daniel

-- 
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
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api