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

[Gareth S Bestor <bestor@xxxxxxxxxx>]

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

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

To	John Levon <john.levon@xxxxxxx>
cc	Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>, xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Subject	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.

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

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