Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-api

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

To: Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: [Xen-API] New API Document and C Bindings
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Fri, 15 Sep 2006 01:50:54 +0100
Cc: xen-api-bounces@xxxxxxxxxxxxxxxxxxx, Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 14 Sep 2006 17:51:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OF725B0774.686BDD4D-ON852571EA.00016BDE-852571EA.0001B710@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>
References: <OF80975B35.2A298B34-ON882571E9.007CB7DC-882571E9.007E1222@xxxxxxxxxx> <OF725B0774.686BDD4D-ON852571EA.00016BDE-852571EA.0001B710@xxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Thu, Sep 14, 2006 at 08:18:44PM -0400, Stefan Berger wrote:
> xen-api-bounces@xxxxxxxxxxxxxxxxxxx wrote on 09/14/2006 06:57:01 PM:
> 
> > Whilst I dont disagree that in Xen the Dom0 (and to be driver 
> > domains, stub domains, etc) have a lot of management characteristic 
> > in common with DomU's, in the fundamental DMTF System Virt model 
> > there is a clear distinction between the 'host' system - that which 
> > hands out resources/shares - and the 'virtual' or 'guest' systems - 
> > those whom consume these (virtualized) resources.
> > 
> > Of course, that said, there is no particular reason that the Xen API
> > and its objects must mirror this rather black-and-white distinction.
> > And in the case of when we start dealing with lots of different 
> > 'flavors' of domains, there is certianly now a bigger grey area as 
> > to what are pure "guest domains" and what are "management domains". 
> > eg I would have a much harder time justifying Dom0 as unique once 
> > all these other mgmt related domains come into the picture... And 
> > once we can have DomUs essentially 'managing' other DomUs in a 
> > front-end/back-end manner everything goes out the window! :-)
> 
> 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
aren't directly given privilege levels by the HV - they're granted privileged
access to hardware devices / memory regions. So for exmaple, Domain N may be
given privileged access to PCI device Y, and Domain M can be given access
to PCI device X. Domain N & M don't intrinsically have different privilege
levels, its the per-device access rights that's the interesting thing.
Domain-0 currently looks like it has a higher intrinsic privilege, but from
what I understand thats just an artifact of it being given access to all
harware - this won't neccessarily be true long term when hardware gets taken
away from Domain 0 & given directly to individual domains.

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