[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, Feb 02, 2007 at 10:26:23AM -0700, Jim Fehlig wrote:
> 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'.

Yeah that's critical info if apps want to sanity check what kernels they
present to a user as bootable on a host.

> 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.

I think that would be very useful for a number of use cases. I think I'd
previously suggested that for those kind of attributes, we'd want the API to 
take an extra 'scope' argument, allowing a bitwise or of two constants 
SCOPE_CONFIG or SCOPE_GUEST. Which would let us say affect running guest only,
affect config file only, or affect both guest & config.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.