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

[Gareth S Bestor <bestor@xxxxxxxxxx>]

>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

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

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