[Xen-API] Re: [Xen-cim] Xen-API update

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

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
'xm info'.

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.

Regards,
Jim


> 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-cim mailing list
> Xen-cim@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-cim
>   

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api