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: Ronald Perez <ronpz@xxxxxxxxxx>
Subject: Re: [Xen-API] New API Document and C Bindings
From: Gareth S Bestor <bestor@xxxxxxxxxx>
Date: Fri, 15 Sep 2006 06:57:44 -0700
Cc: xen-api-bounces@xxxxxxxxxxxxxxxxxxx, Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 15 Sep 2006 06:58:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OF01865141.E41AFB8F-ON852571EA.000EB58E-852571EA.000FAD8E@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>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

certainly the CIM model supports the notion of 'recursive' virtualization hosting. However, I'm unclear how much of that we want to try and slap into the API for xend; in particular, are you thinking the host system will now running multipe xend's, in different Domains?

- G

Inactive hide details for Ronald Perez/Watson/IBM@IBMUSRonald Perez/Watson/IBM@IBMUS

          Ronald Perez/Watson/IBM@IBMUS
          Sent by: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

          09/14/06 07:51 PM


John Levon <john.levon@xxxxxxx>


xen-api-bounces@xxxxxxxxxxxxxxxxxxx, Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>


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

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

GIF image

xen-api mailing list