Re: [Xen-API] Xen-API update

[Ingard Mevåg <ingard.mevag@xxxxxxxxxxxxxx>]

This is excellent news.

I'm doing my master thesis this semester about (in short) management and
monitoring of a virtual infrastructure. In this project I also plan to
develop a tool which will calculate the total redundancy level of the VI
and, among other things, also be able to live migrate VMs to give them
more available resources if need be. It is also meant for this tool to
be able to communicate with hartbeat to ensure availability in the
virtual infrastructure if physical nodes do, in worst case, go down
unexpectantly.

I will need to collect statistics of the resource consumption in the
different VMs and the new Xen-api seems like the best approach to do
this. I have been recommended to look at xenmon also for this task and I
would very much like more opinions on this matter. I am aware that I
have the option of enabling statistics outpit from Xen, but also that
this might cause a performance hit on about 10% which is unacceptable
since this tool is ment to be used in production systems.

I hope to hear about experiences and opinions from other people on this
list that might have been in the same situation or had a similar task,
or just opinions and advice in general.

Ingard
Oslo University College
Norway

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 ;-)
>
> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
>   


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