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

Re: [Xen-API] New API Document and C Bindings



>Its probably unrealistic to come up with a complete set ahead of time, so
>we probably need an initial basic set which is expanded over time.

Well, for what its worth, the wolf closest to *my* door is the DMTF System Virtualization model... :-)

- Gareth

Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186

Inactive hide details for "Daniel P. Berrange" <berrange@xxxxxxxxxx>"Daniel P. Berrange" <berrange@xxxxxxxxxx>


          "Daniel P. Berrange" <berrange@xxxxxxxxxx>

          09/15/06 07:36 AM

          Please respond to
          "Daniel P. Berrange" <berrange@xxxxxxxxxx>

To

Ronald Perez/Watson/IBM@IBMUS

cc

Gareth S Bestor/Beaverton/IBM@IBMUS, xen-api-bounces@xxxxxxxxxxxxxxxxxxx, Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>

Subject

Re: [Xen-API] New API Document and C Bindings

On Fri, Sep 15, 2006 at 10:07:56AM -0400, Ronald Perez wrote:
> Gareth S Bestor/Beaverton/IBM wrote on 09/15/2006 09:57:44 AM:
>
> > certainly the CIM model supports the notion of 'recursive'
> virtualization hosting.
> > However, I'm unclear how much of that we want to try and slap into the
> API for
> > xend; in particular, are you thinking the host system will now running
> multipe
> > xend's, in different Domains?
> >
> > - G
> >
>
>
> You're correct to point out the differences between the CIM modeling goals
> and the Xen API (thanks, at this early stage, I often confuse the two).
>
> I guess I'm saying that the Xen API should not preclude such a direct
> mapping from model -> implementation. In practical terms, this could
> include the existence of multiple xend's (or equivalent) on a platform.
> This could be for the parent -> child scenario I mentioned before, or it
> could just be a high availability issue (e.g., sort of a dom0 hot
> back-up). Granted, there's a lot of clever engineering needed to make any
> of these scenarios a reality :-)
>
> So in summary, I tend to agree more with John's and Dan's approach (but
> I'd like to see some details in regard to the capabilities Dan mentions).

That's the $1,000,000 question :-) Just what capabilities do we need to
represent to meet the needs of management applications using the API ?
So far this thread has mentioned what lifecycle states are possible for
a given domain, and what resource adjustments can be made to a domain.
Its probably unrealistic to come up with a complete set ahead of time, so
we probably need an initial basic set which is expanded over time.

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

GIF image

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