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:04:46 -0700
Cc: xen-api-bounces@xxxxxxxxxxxxxxxxxxx, Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 15 Sep 2006 07:05:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060915122351.GB15823@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

I'm kinda leaning towards what Dan is thinking - right now Dom0 is 'special' only because it is the one Domain given administrative control of all the host resources. But if this role is effectively farmed out to future drive and stub domains, and this ability can be added arbitrarily to *any* domain, then effectively any domain can assume the role of a (partial) management domain at any time, so we're basically left with a flat model - ie "all domains are created equal" :-)

- 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>
          Sent by: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

          09/15/06 05:23 AM
          Please respond to
          "Daniel P. Berrange" <berrange@xxxxxxxxxx>


John Levon <john.levon@xxxxxxx>


Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>, xen-api-bounces@xxxxxxxxxxxxxxxxxxx


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

On Fri, Sep 15, 2006 at 02:08:36AM +0100, John Levon wrote:
> On Fri, Sep 15, 2006 at 01:50:54AM +0100, Daniel P. Berrange wrote:
> > > In that case I would suggest introducing a privileged flag for the VM
> > > classes. Maybe that ends up being a distinguishing factor between VMs like
> > > dom-0, driver domains and other guests.
> >
> > Except that its not really representative of what's going on - it implies
> > a discrete set of privilege levels can be assigned to domains. Domains
> More generally it sounds like their needs to be two classes, one a sub-class of
> the other. Certain things (vcpu pinnings, resource utilisation data) belong in
> the superclass, other stuff in the other. Certainly the API would need to allow
> people to identify what /kind/ of domain a particular representation is.

I'm still not convinced that there's any particularly useful classification
of different domains. Each domain has a varying & overlapping set of
capabilities which can't easily be put into a strict hierarchy. Thus I
think it would be more useful to keep a flat classification of all domains,
and instead explicitly attach a set of capability flags to each domain. Apps
aren't really concerned with is this Domain type X, or Y - they are concerned
with what capabilities type X or Y has. Attaching capabilities directly to
individual domains is much more flexible than infering capabilities from
a 'type' approximation.

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

GIF image

xen-api mailing list