Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-api

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

To: Ronald Perez <ronpz@xxxxxxxxxx>
Subject: Re: [Xen-API] New API Document and C Bindings
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Fri, 15 Sep 2006 15:36:05 +0100
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>, xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 15 Sep 2006 07:36:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OFCF3C0736.2B92740D-ON852571EA.004CD8AD-852571EA.004DA1D5@xxxxxxxxxx>
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: <OFEF081C64.B61B9289-ON882571EA.004C7507-882571EA.004CB2C2@LocalDomain> <OFCF3C0736.2B92740D-ON852571EA.004CD8AD-852571EA.004DA1D5@xxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
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