[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-API] New API Document and C Bindings
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" :-)
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |