This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: John Levon <john.levon@xxxxxxx>
Subject: Re: [Xen-API] New API Document and C Bindings
From: Ronald Perez <ronpz@xxxxxxxxxx>
Date: Thu, 14 Sep 2006 22:51:14 -0400
Cc: xen-api-bounces@xxxxxxxxxxxxxxxxxxx, Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 14 Sep 2006 19:51:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060915010835.GA26480@xxxxxxxxxxxxxxxxx>
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>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

John Levon wrote on 09/14/2006 09:08:36 PM:

> 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.
> regards
> john

I think (thought) this sub-class concept is exactly what was briefly discussed at the Xen Summit. The context then also included the possibility (which I believe Ian had supported in his roadmap) that a guest VM could [someday] donate some of it's resources to create another VM, a child VM, and yet [optionally] still retain some level of control over that child VM and it's resources -- much as a host does for it's domU's. Further, guest VMs (domU's) may also be running CIM providers for various things, and those providers could likely be virtualization unaware (they would think the system they were managing was a host). So could we be looking at a recursive definition?

xen-api mailing list