Ewan Mellor wrote:
> 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 ;-)
Great progress - thanks for all the work :-).
> 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.
The host class could use a capabilities field, perhaps a set of strings
describing supported guests - similar to 'xen_caps' field produced by
We've talked in the past about changing config of running guest vs
changing its stored config. I would like to hotplug memory, cpu, disks,
etc on a running guest but have it use stored config on next activation.
Likewise it would be useful to change the stored config, regardless of
guest state, for application on next activation.
> 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,
> Xen-cim mailing list
xen-api mailing list