WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

Re: [Xen-API] Xen-API update

To: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-API] Xen-API update
From: Ingard Mevåg <ingard.mevag@xxxxxxxxxxxxxx>
Date: Fri, 02 Feb 2007 15:22:05 +0100
Delivery-date: Fri, 02 Feb 2007 06:21:34 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070130232504.GA4206@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <20070130232504.GA4206@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.9 (X11/20070103)
I just noticed there is no vm_metrics class available from xendapi.py
which makes it (as far as i understood) inacessible from the api. Is
this work in progress? If so, when is it planned to be included in the
unstable tree?

I saw the documentation is in place already so that is why im asking. I
am pretty new to xen so i might have done something wrong when mirroring
the tree. I used the following command:
    "hg clone http://xenbits.xensource.com/xen-unstable.hg";

Is this the correct thing to do to get the most updated copy?

Ingard

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

<Prev in Thread] Current Thread [Next in Thread>