|
|
|
|
|
|
|
|
|
|
xen-api
Re: [Xen-API] New API Document and C Bindings
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
Ronald Perez/Watson/IBM@IBMUS
Ronald Perez/Watson/IBM@IBMUS
Sent by: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
09/14/06 07:51 PM
|
|
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?
-Ron_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
_______________________________________________
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, (continued)
- 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
- Re: [Xen-API] New API Document and C Bindings, John Levon
- Re: [Xen-API] New API Document and C Bindings, John Levon
Re: [Xen-API] New API Document and C Bindings, Ronald Perez
|
|
|
|
|