Here's a quick update on the Xen-API work; I thought that with the large
number of changesets that have gone in today that you might be curious ;-)
We had an internal review of the API last week here at XenSource, and what
you've seen today is the result of that. The goal is to have an interface in
Xen 3.0.5 that we will call the Xen-API 1.0, and that we will maintain in a
backwards-compatible fashion for the long term. With that in mind, some of
our "future hopes" that were still unimplemented have been bumped out, and
where we felt that we needed more flexibility, we've made provision for that
too. I think that API that we've settled on is in good shape, and is
certainly something that we can stand behind, and maintain going forward.
I've still got a few more changes to push through over the next day or two,
and when that's done I'll be marking this API version 0.9, to emphasise the
approaching deadline.
If you've not already done so, now is the time to try out what we've got.
This is the _only_ API for Xen that will be maintained in the long term, so if
there's something that you need for your product or your pet project, now is
the time to shout! We have both Python and C client-side bindings in the
tree, and a number of example scripts to get you started, and I'd be very
interested in your feedback.
For those who've been following along at home, here's a summary of the recent
changes and those coming up in the next couple of days:
o Improved console support: the Console class has gained additional fields
to allow VNC passwords, the X DISPLAY for SDL, and similar configuration to
be passed through, both to QEMU and to the paravirtual frame buffer driver.
o Extended VCPU scheduling and pinning parameters, bringing the Xen-API up
to parity with the legacy protocols.
o Metrics classes: I've split the I/O and memory metrics on VM, host, PIF,
VIF, and VBD out into separate classes from the main data class. In other
words, there is now a host_metrics class as well as the host class. These
statistics have very different access patterns and rates of change,
when compared with the object to which they apply, so it makes to have them
held in a separate object.
o The asynchronous method calls are now supported by Xend. For example,
you may call Async.VM.start which will return immediately with a task handle,
and then you may poll the status of that request asynchronously until it
completes. These calls are not yet in the C bindings (coming soon!) but you
can make these calls using the Python bindings (or xm shell) today.
o True asynchronous event support is on its way, with a simple registration
/ blocking-poll mechanism for notifications.
o VTPM handling has been tidied up (thanks to Stefan Berger for that one)
o Improved storage handling has been added with a new PBD class. This will
give Xend room for configuration details related to storage repositories, and
extends the model to show symmetry between network and storage handling.
o The presence and location of crash-dumps and suspend images may be
interrogated through the API, using the same VDI API as for VM disk images.
The plan for the next couple of days is to finish up getting these changes
into xen-unstable, and then look to flesh out xm and the test programs. At
the same time, there will be a little bit of work to the Xen-CIM providers to
match these recent changes, and then we'll be in an excellent position to
stabilise Xend and the CIM providers for the 3.0.5 release.
All the best,
Ewan.
_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
number of changesets that have gone in today that you might be curious ;-)
We had an internal review of the API last week here at XenSource, and what
you've seen today is the result of that. The goal is to have an interface in
Xen 3.0.5 that we will call the Xen-API 1.0, and that we will maintain in a
backwards-compatible fashion for the long term. With that in mind, some of
our "future hopes" that were still unimplemented have been bumped out, and
where we felt that we needed more flexibility, we've made provision for that
too. I think that API that we've settled on is in good shape, and is
certainly something that we can stand behind, and maintain going forward.
I've still got a few more changes to push through over the next day or two,
and when that's done I'll be marking this API version 0.9, to emphasise the
approaching deadline.
If you've not already done so, now is the time to try out what we've got.
This is the _only_ API for Xen that will be maintained in the long term, so if
there's something that you need for your product or your pet project, now is
the time to shout! We have both Python and C client-side bindings in the
tree, and a number of example scripts to get you started, and I'd be very
interested in your feedback.
For those who've been following along at home, here's a summary of the recent
changes and those coming up in the next couple of days:
o Improved console support: the Console class has gained additional fields
to allow VNC passwords, the X DISPLAY for SDL, and similar configuration to
be passed through, both to QEMU and to the paravirtual frame buffer driver.
o Extended VCPU scheduling and pinning parameters, bringing the Xen-API up
to parity with the legacy protocols.
o Metrics classes: I've split the I/O and memory metrics on VM, host, PIF,
VIF, and VBD out into separate classes from the main data class. In other
words, there is now a host_metrics class as well as the host class. These
statistics have very different access patterns and rates of change,
when compared with the object to which they apply, so it makes to have them
held in a separate object.
o The asynchronous method calls are now supported by Xend. For example,
you may call Async.VM.start which will return immediately with a task handle,
and then you may poll the status of that request asynchronously until it
completes. These calls are not yet in the C bindings (coming soon!) but you
can make these calls using the Python bindings (or xm shell) today.
o True asynchronous event support is on its way, with a simple registration
/ blocking-poll mechanism for notifications.
o VTPM handling has been tidied up (thanks to Stefan Berger for that one)
o Improved storage handling has been added with a new PBD class. This will
give Xend room for configuration details related to storage repositories, and
extends the model to show symmetry between network and storage handling.
o The presence and location of crash-dumps and suspend images may be
interrogated through the API, using the same VDI API as for VM disk images.
The plan for the next couple of days is to finish up getting these changes
into xen-unstable, and then look to flesh out xm and the test programs. At
the same time, there will be a little bit of work to the Xen-CIM providers to
match these recent changes, and then we'll be in an excellent position to
stabilise Xend and the CIM providers for the 3.0.5 release.
All the best,
Ewan.
_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api