[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |