Xen-API Weekly Call, 12 June 2006, Minutes
==========================================
Attending:
Jim Fehlig, Novell.
Ewan Mellor, XenSource.
Shishir Pardikar, XenSource.
Daniel Veillard, Red Hat.
The phone call was mainly taken up by discussion of the new C bindings
proposed by Ewan and posted to the Xen-API mailing list that day. There was
also discussion of general Xend performance problems, and the plan moving
forward, including an offer of development effort from Jim.
C Bindings
----------
The C bindings were posted to the Xen-API mailing list a couple of hours
before the call. With such a short lead time, of course most people had not
had time to absorb the proposal, so a short time was spent talking through the
approach.
A number of changes were proposed, mainly by Daniel Veillard, and these will
be folded into the next version of the proposal. The changes are:
o Add a call to explicitly free each of the object handles (xen_vm in the
given example), rather than stating that the caller should free it. This
allows the binding to decide how to allocate these handles.
o Add a call such that a struct can be populated in one go, rather than
requiring a number of calls to read each field in turn from the server.
o Add the ability to get a UUID as a packed 16 byte value rather than the
readable form used at the moment, for compatibility with libvirt.
o Add a version number to the interface.
o Add padding to all structures, to make it easier to preserve ABI
compatibility.
There was much discussion of xen_vm_create, and how parameters should be
passed in to these calls. Ewan made it clear that the example shows only a
few fields, and that it was intended in the example that all fields marked
ROins and RW in the API document would be passed into the xen_vm_create call,
each as a a separate parameter.
It was proposed instead that a structure could be passed into this call (the
same as the struct that will populated by the call mentioned above), rather
than having to give each field individually. Alternatively, an XML fragment
could be passed in, and that used to populate the new object instead. Daniel
said that libvirt used to use an XML fragment, but that it was changed to use
a struct, because libvirt's users did not want to manipulate XML themselves.
There was discussion of the way that Sets are handled in the interface.
Daniel said that he did not like the fact that Sets are returned as a
malloc()d array by the API, with the caller expected to free() that array
later. He would rather that the caller could allocate space for the array,
and then pass this space into the API in order to be filled. This would allow
the caller to allocate memory in any way they chose, including on the stack.
Ewan pointed out that this leaves you with a race condition, whereby you make
a call to find out how big the array has to be, but then this subsequently
changes, causing you to have to retry.
A solution that all are happy with was not found.
Performance Problems with Xend
------------------------------
Daniel reported measurements taken on the throughput of Xend, where he was
achieving only 20 Xend calls per second (through the HTTPU interface) before
becoming CPU bound. The CPU usage was attributed both to Xend and Xenstored.
Ewan said that it has been known for Xend to use transactions, even around
single reads, and that if there are still places where this is happening, then
these will cause the observed behaviour. If this is happening, these will
need to be found and eliminated.
Development Effort
------------------
Jim offered some time for Xen-API development, and though he is unable to
offer enough to be able to lead a project at the moment, he should have enough
time available for "grunt work" (as he put it ;-). This offer is gratefully
received, and we will certainly make use of his time. Ewan will continue to
lead the development of the API and bindings, and will contact Jim when work
is available.
Action Points
-------------
Ewan to implement the C binding changes above, including adding aggregate
alternatives to xen_vm_create.
Ewan to revise the API document as per the To-do list therein, and to clarify
points left unspecified in the document that have been shaken out by the C
binding work.
Daniel, time permitting, to reproduce poor performance in Xend and see whether
unnecessary Xenstore transactions are occurring. (Daniel didn't promise to do
this, but if he's got time, it would certainly be appreciated ;-)
Jim to watch this space until we're ready to get on with the grunt work!
Next Call
---------
The next call clashes with OLS, which may make it difficult for a number of
people to attend. Gareth Bestor will decide whether to proceed with the call
that week.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home