On Sun, Jun 25, 2006 at 03:52:23AM -0400, Daniel Veillard wrote:
> 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 understand your arguments here, especially the point about the cost of using
Xend for second-by-second load monitoring. What's interesting here is that
this places libvirt in a curious place, architecturally.
I see the management stack looking like this:
Tools
-----
Binding to XML-RPC
-----
|
| XML-RPC (standard and fixed)
|
-----
Binding to XML-RPC
-----
Xend
---------------------
libxc libxs
----- -----
Hypervisor Xenstored
This has a number of notable features:
o The tools, once compiled, are not tied to a specific version of Xen.
o The existence of Xenstored is not implied at the interface -- it's an
implementation detail.
o The tools do not need to run on the managed node.
o The tools don't need to run as root to make modifications -- they can
authenticate over the XML-RPC to Xend, which is the only thing that needs to
run as root.
What you are saying is that libvirt is not intended to be near the top of this
stack, but instead will talk to Xend (over XML-RPC) or libxc, or libxs as it
sees fit. That's fine, but it's very different to what I _thought_ you were
trying to do!
Your design has a number of tradeoffs:
o Performance-critical stuff is much easier to do.
o Tools compiled against libvirt will be fixed to that version of the
hypervisor, will have to run as root to make modifications, and will need to
run on the managed node.
o libvirt will have to be kept in sync with changes in Xend that change the
store layout (this is currently an undocumented interface, though it's pretty
stable).
To address the load-monitoring concerns, we clearly have to do something. I
would say that remote access to the node is still important, so we need to
design a "cooked" interface to the load statistics, one that is suitable for
use across the wire. You clearly wouldn't poll the managed host for each stat
individually every second if you were talking to it remotely. We need to
instead design an API that looks something like "please give me the
thirty-second load average for the following list of stats", with the
monitoring, trending, and averaging being done on the managed host.
> 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.
That certainly clarifies things a lot, thank you! A C binding would still be
useful -- it could be the bottom end of your Xend interface plugin, for
example. It's obviously only a small portion of the problem that libvirt is
trying to solve, that's the difference.
Ewan.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home