| |
|
 |
|
 |
|
|
|
| |
|
|
xen-api
Re: [Xen-API] Xen Management API draft
Ewan Mellor wrote:
Attached is a draft Xen Management API. This document presents our ideas in
terms of a data model, with an implied binding to XML-RPC calls. There are a
few examples in there too -- hopefully it's clear how the mapping between the
document and the wire protocol.
Thanks Ewan.
In particular, we need to get this API into a state so that it is the right
API for Xen-CIM. We need to think whether libvirt is ready to rely upon this
API too. That would mean moving the hypercalls and Xenstore reads and writes
out of libvirt, and pushing it up the stack alongside the other client-side
bindings.
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. (Makes me thing of Uncertainty
Principle or Observer Effect, i.e. we crank up cpu utilization by asking
for cpu utilization :-)). I guess the hypercalls and Xenstore
reads/writes mentioned above would still exist but not be part of the
"guarantees" for Xen.
Many of the RPCs return void, e.g. VM.start(), VM.pause(), etc. How are
failures indicated? Via the Status and ErrorDescription elements of
return value struct?
Regards,
Jim
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
|
|
| |
|
Home