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