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/
Home Products Support Community News


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

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Subject: Re: [Xen-API] New API Document and C Bindings
From: Gareth S Bestor <bestor@xxxxxxxxxx>
Date: Fri, 15 Sep 2006 07:55:51 -0700
Cc: xen-api-bounces@xxxxxxxxxxxxxxxxxxx, Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 15 Sep 2006 07:56:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060915143605.GD13130@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>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

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


Ronald Perez/Watson/IBM@IBMUS


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


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.

|=- 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
<Prev in Thread] Current Thread [Next in Thread>