xen-api
Re: [Xen-API] New API Document and C Bindings
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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-API] New API Document and C Bindings, Ewan Mellor
- Re: [Xen-API] New API Document and C Bindings, Stefan Berger
- Re: [Xen-API] New API Document and C Bindings, Ewan Mellor
- Re: [Xen-API] New API Document and C Bindings, John Levon
- Re: [Xen-API] New API Document and C Bindings, Gareth S Bestor
- Re: [Xen-API] New API Document and C Bindings, Jim Fehlig
- Re: [Xen-API] New API Document and C Bindings, Daniel P. Berrange
- Re: [Xen-API] New API Document and C Bindings, Gareth S Bestor
- Re: [Xen-API] New API Document and C Bindings, Stefan Berger
- Re: [Xen-API] New API Document and C Bindings,
Daniel P. Berrange <=
- Re: [Xen-API] New API Document and C Bindings, John Levon
- Re: [Xen-API] New API Document and C Bindings, Ronald Perez
- Re: [Xen-API] New API Document and C Bindings, Gareth S Bestor
- Re: [Xen-API] New API Document and C Bindings, Daniel P. Berrange
- Re: [Xen-API] New API Document and C Bindings, Gareth S Bestor
- Re: [Xen-API] New API Document and C Bindings, Ronald Perez
- Re: [Xen-API] New API Document and C Bindings, Daniel P. Berrange
- Re: [Xen-API] New API Document and C Bindings, Ronald Perez
- Re: [Xen-API] New API Document and C Bindings, Daniel P. Berrange
- Re: [Xen-API] New API Document and C Bindings, Gareth S Bestor
|
|
|