Mailing List Archive

Hello!

I had a look at the much more explicit enumeration of accessor functions
for each one of the defined class. I am wondering what the rationale
behind some of the set-ters is. For example the VIF class has members
type, device, network, VM etc. Shouldn't these be marked RO_ins and have
no associated set-ters after object creation? Can you actually change the
type once the object has been created or move the VIF to another VM
(set_VM)? Similar on VBD.

Regards,
Stefan

xen-api-bounces@lists.xensource.com wrote on 08/25/2006 02:58:21 PM:


>
> Hi all,
>
> I've put a new version of the Xen Management API document and the
> corresponding C bindings on the Xen-API wiki page (and they are
attached).
> There's nothing very exciting in the document -- I've just updated the
todo
> list, basically.
>
> The C bindings have been updated to the new way of passing results back
and
> handling errors. The API calls now look a lot like this:
>
> xen_vm vm;
> if (!xen_vm_get_by_uuid(session, &vm,
> "00000000-0000-0000-0000-000000000000"))
> {
> print_error(session);
> CLEANUP;
> return 1;
> }
>
> That is, you pass a pointer to the result destination, which will
befilled if
> the call is successful, or NULL otherwise, and you get a boolean result
from
> the actual function call to tell you whether or not an error occurred.
>
> I've also added the appropriate casts so that this code compiles under
GCC 4.0
> with -Werror.
>
> Have fun hacking, and to all the Brits out there, happy holidays,
>
> Ewan.
>
> [attachment "xenapi-0.4.3.pdf" deleted by Stefan Berger/Watson/IBM]
> [attachment "libxen-src-0.4.3-2.tar.bz2" deleted by Stefan
> Berger/Watson/IBM] _______________________________________________
> xen-api mailing list
> xen-api@lists.xensource.com
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Mon, Aug 28, 2006 at 04:13:10PM -0400, Stefan Berger wrote:

> Hello!
>
> I had a look at the much more explicit enumeration of accessor functions
> for each one of the defined class. I am wondering what the rationale
> behind some of the set-ters is. For example the VIF class has members
> type, device, network, VM etc. Shouldn't these be marked RO_ins and have
> no associated set-ters after object creation? Can you actually change the
> type once the object has been created or move the VIF to another VM
> (set_VM)? Similar on VBD.

I'm not sure sure about Vif.network -- it might be possible to redirect the
VIF to a different network, though obviously that's going to require the guest
to figure that out too, so that one might be a little bit complicated. The
rest though, yes, you're right, they should just be RO_ins -- that's a
mistake.

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Also I have a question regarding domain-0. How will it be represented? Is
it a VM - the fact that 'guest' is written in the description of the VM
class makes me think that this might not be the case.


Stefan

Ewan Mellor <ewan@xensource.com> wrote on 09/05/2006 08:40:59 AM:

> On Mon, Aug 28, 2006 at 04:13:10PM -0400, Stefan Berger wrote:
>
> > Hello!
> >
> > I had a look at the much more explicit enumeration of accessor
functions
> > for each one of the defined class. I am wondering what the rationale
> > behind some of the set-ters is. For example the VIF class has members
> > type, device, network, VM etc. Shouldn't these be marked RO_ins and
have
> > no associated set-ters after object creation? Can you actually change
the
> > type once the object has been created or move the VIF to another VM
> > (set_VM)? Similar on VBD.
>
> I'm not sure sure about Vif.network -- it might be possible to redirect
the
> VIF to a different network, though obviously that's going to requirethe
guest
> to figure that out too, so that one might be a little bit complicated.
The
> rest though, yes, you're right, they should just be RO_ins -- that's a
> mistake.
>
> Ewan.

On Tue, Sep 12, 2006 at 07:16:40PM -0400, Stefan Berger wrote:

> Also I have a question regarding domain-0. How will it be represented? Is
> it a VM - the fact that 'guest' is written in the description of the VM
> class makes me think that this might not be the case.

That's a very good question. My instinct is to say that dom-0 shouldn't
be part of the list of domains, and that it should be considered part of
the infrastructure. When we have driver domains, and HVM stub domains,
there will be many of these domains, representing different parts of the
infrastructure, and it seems to me that these are not the same as
"guests" or "VMs". A VM can be rebooted, migrated (possibly), each time
keeping the same VM, but ending up with a different domain. A VM is
ultimately the reason that users are running Xen, and the thing that
makes it useful. For this reason, I don't think that domain 0 is a VM.

On the other hand, these things are still useful entities -- you might
want to monitor the CPU cost due to each of them, tweak their scheduling
parameters, and so on. So perhaps they are close enough to being a VM
that we should put them in there, and cope with the slightly special
nature of them as best we can.

What do people think?

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Thu, Sep 14, 2006 at 06:23:25AM +0100, Ewan Mellor wrote:

> > Also I have a question regarding domain-0. How will it be represented? Is
> > it a VM - the fact that 'guest' is written in the description of the VM
> > class makes me think that this might not be the case.
>
> That's a very good question. My instinct is to say that dom-0 shouldn't
> be part of the list of domains, and that it should be considered part of
> the infrastructure. When we have driver domains, and HVM stub domains,
> there will be many of these domains, representing different parts of the
> infrastructure, and it seems to me that these are not the same as
> "guests" or "VMs". A VM can be rebooted, migrated (possibly), each time
> keeping the same VM, but ending up with a different domain. A VM is
> ultimately the reason that users are running Xen, and the thing that
> makes it useful. For this reason, I don't think that domain 0 is a VM.
>
> On the other hand, these things are still useful entities -- you might
> want to monitor the CPU cost due to each of them, tweak their scheduling
> parameters, and so on. So perhaps they are close enough to being a VM
> that we should put them in there, and cope with the slightly special
> nature of them as best we can.
>
> What do people think?

Sounds like you want the notion of 'domain', where it may have an attached
'guest' or whatever. For the special ones, the attached guest doesn't exist (or
possibly refers to the real VM for a stub domain?).

I think it's essential that they are represented /somehow/ in the API anyway,
precisely because of the reasons you list.

regards
john

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

I agree. Dom0 tastes more like the virtualization 'host', and treating it
as a special DomU will probably may just make everybody's life more
complicated (eg lots of 'if (domid == 0) {} else {}' ...)

The DMTF model has the notion of guests/VMs, and a separate the 'host'
system. Certainly, the interesting and useful aspects of the host system
as exposed thru Dom0 need to and will be tbe exposed via CIM interfaces,
either sitting on top of libxen or else sitting on top of the Dom0 OS
(which is largely what we're doing today running the OMC providers in Dom0
to expose host info).

Personally, I think Dom0 corresponds to an HMC
(http://en.wikipedia.org/wiki/Hardware_Management_Console), which
certainly has its own mgmt interfaces, but which are largely different
that those needed to manage hosted guests/partitions.

my $0.02...

- Gareth

Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186




Ewan Mellor <ewan@xensource.com>
Sent by: xen-api-bounces@lists.xensource.com
09/13/2006 10:23 PM

To
Stefan Berger/Watson/IBM@IBMUS
cc
Xen-API <xen-api@lists.xensource.com>
Subject
Re: [Xen-API] New API Document and C Bindings






On Tue, Sep 12, 2006 at 07:16:40PM -0400, Stefan Berger wrote:

> Also I have a question regarding domain-0. How will it be represented?
Is
> it a VM - the fact that 'guest' is written in the description of the VM
> class makes me think that this might not be the case.

That's a very good question. My instinct is to say that dom-0 shouldn't
be part of the list of domains, and that it should be considered part of
the infrastructure. When we have driver domains, and HVM stub domains,
there will be many of these domains, representing different parts of the
infrastructure, and it seems to me that these are not the same as
"guests" or "VMs". A VM can be rebooted, migrated (possibly), each time
keeping the same VM, but ending up with a different domain. A VM is
ultimately the reason that users are running Xen, and the thing that
makes it useful. For this reason, I don't think that domain 0 is a VM.

On the other hand, these things are still useful entities -- you might
want to monitor the CPU cost due to each of them, tweak their scheduling
parameters, and so on. So perhaps they are close enough to being a VM
that we should put them in there, and cope with the slightly special
nature of them as best we can.

What do people think?

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Ewan Mellor wrote:
> On Tue, Sep 12, 2006 at 07:16:40PM -0400, Stefan Berger wrote:
>
>
>> Also I have a question regarding domain-0. How will it be represented? Is
>> it a VM - the fact that 'guest' is written in the description of the VM
>> class makes me think that this might not be the case.
>>
>
> That's a very good question. My instinct is to say that dom-0 shouldn't
> be part of the list of domains, and that it should be considered part of
> the infrastructure. When we have driver domains, and HVM stub domains,
> there will be many of these domains, representing different parts of the
> infrastructure, and it seems to me that these are not the same as
> "guests" or "VMs". A VM can be rebooted, migrated (possibly), each time
> keeping the same VM, but ending up with a different domain. A VM is
> ultimately the reason that users are running Xen, and the thing that
> makes it useful. For this reason, I don't think that domain 0 is a VM.
>
> On the other hand, these things are still useful entities -- you might
> want to monitor the CPU cost due to each of them, tweak their scheduling
> parameters, and so on. So perhaps they are close enough to being a VM
> that we should put them in there, and cope with the slightly special
> nature of them as best we can.
>
> What do people think?
>

Even though dom0 is part of the infrastructure (or as Gareth pointed out
akin to a HMC), it still needs to be managed and many of the management
functions are no different from 'normal' guests. VCPUs can be
hot-plugged and pinned to PCPUs, memory can be added / removed, etc.
From the perspective of adding / removing resources, dom0 is no
different than any other VM.

Driver and stub domains appear to be implementation details. A
management app shouldn't have to know or care about them, at least not
in the same regard as normal VMs. That said, I still see the need to be
able to control the resources of such infrastructure domains - again
such as restricting the PCPUs these domains can run on.

Guess I haven't said anything new - just added to the uncertainty of how
we are going to handle these infrastructure domains that require a
subset of the management functionality of their first-class brethren :-).

Jim


_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Thu, Sep 14, 2006 at 03:36:35PM -0600, Jim Fehlig wrote:
> Ewan Mellor wrote:
> >On Tue, Sep 12, 2006 at 07:16:40PM -0400, Stefan Berger wrote:
> >
> >
> >>Also I have a question regarding domain-0. How will it be represented? Is
> >>it a VM - the fact that 'guest' is written in the description of the VM
> >>class makes me think that this might not be the case.
> >>
> >
> >That's a very good question. My instinct is to say that dom-0 shouldn't
> >be part of the list of domains, and that it should be considered part of
> >the infrastructure. When we have driver domains, and HVM stub domains,
> >there will be many of these domains, representing different parts of the
> >infrastructure, and it seems to me that these are not the same as
> >"guests" or "VMs". A VM can be rebooted, migrated (possibly), each time
> >keeping the same VM, but ending up with a different domain. A VM is
> >ultimately the reason that users are running Xen, and the thing that
> >makes it useful. For this reason, I don't think that domain 0 is a VM.
> >
> >On the other hand, these things are still useful entities -- you might
> >want to monitor the CPU cost due to each of them, tweak their scheduling
> >parameters, and so on. So perhaps they are close enough to being a VM
> >that we should put them in there, and cope with the slightly special
> >nature of them as best we can.
> >
> >What do people think?
> >
>
> Even though dom0 is part of the infrastructure (or as Gareth pointed out
> akin to a HMC), it still needs to be managed and many of the management
> functions are no different from 'normal' guests. VCPUs can be
> hot-plugged and pinned to PCPUs, memory can be added / removed, etc.
> From the perspective of adding / removing resources, dom0 is no
> different than any other VM.

I agree - having Dom0 represented in exactly same way as any other guest
makes writing management apps very easy because we don't have to special
case code. Sure there some operations you can't apply to Dom0 (such as
suspend, migrate, etc), but equally there are some operations you can't
apply to HVM guests (eg memory ballooning, suspend, migrate). There is
plenty in common between Dom0 and other guests - which Jim lists here -
which makes it a net win IMHO to treat Dom0 just like any other DomU.

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

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!
:-)

So perhaps for Xen at least, maybe it does not (or soon will not) make
sense to distinguish between the two in the API, and instead let the CIM
stuff sitting on top what whatever black-and-white distinctions are
required to satisfy the formal DMTF model.

interesting... good points... :-)

- Gareth

Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186




"Daniel P.
Berrange"
<berrange@redhat. To
Sent by: cc
xen-api-bounces@l Xen-API
ists.xensource.co <xen-api@lists.xensource.com>
m Subject
Re: [Xen-API] New API Document and
C Bindings
09/14/06 02:47 PM


Please respond to
"Daniel P.
Berrange"
<berrange@redhat.






On Thu, Sep 14, 2006 at 03:36:35PM -0600, Jim Fehlig wrote:
> Ewan Mellor wrote:
> >On Tue, Sep 12, 2006 at 07:16:40PM -0400, Stefan Berger wrote:
> >
> >
> >>Also I have a question regarding domain-0. How will it be represented?
Is
> >>it a VM - the fact that 'guest' is written in the description of the VM
> >>class makes me think that this might not be the case.
> >>
> >
> >That's a very good question. My instinct is to say that dom-0 shouldn't
> >be part of the list of domains, and that it should be considered part of
> >the infrastructure. When we have driver domains, and HVM stub domains,
> >there will be many of these domains, representing different parts of the
> >infrastructure, and it seems to me that these are not the same as
> >"guests" or "VMs". A VM can be rebooted, migrated (possibly), each time
> >keeping the same VM, but ending up with a different domain. A VM is
> >ultimately the reason that users are running Xen, and the thing that
> >makes it useful. For this reason, I don't think that domain 0 is a VM.
> >
> >On the other hand, these things are still useful entities -- you might
> >want to monitor the CPU cost due to each of them, tweak their scheduling
> >parameters, and so on. So perhaps they are close enough to being a VM
> >that we should put them in there, and cope with the slightly special
> >nature of them as best we can.
> >
> >What do people think?
> >
>
> Even though dom0 is part of the infrastructure (or as Gareth pointed out
> akin to a HMC), it still needs to be managed and many of the management
> functions are no different from 'normal' guests. VCPUs can be
> hot-plugged and pinned to PCPUs, memory can be added / removed, etc.
> From the perspective of adding / removing resources, dom0 is no
> different than any other VM.

I agree - having Dom0 represented in exactly same way as any other guest
makes writing management apps very easy because we don't have to special
case code. Sure there some operations you can't apply to Dom0 (such as
suspend, migrate, etc), but equally there are some operations you can't
apply to HVM guests (eg memory ballooning, suspend, migrate). There is
plenty in common between Dom0 and other guests - which Jim lists here -
which makes it a net win IMHO to treat Dom0 just like any other DomU.

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

xen-api-bounces@lists.xensource.com 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.

Stefan

>
> So perhaps for Xen at least, maybe it does not (or soon will not)
> make sense to distinguish between the two in the API, and instead
> let the CIM stuff sitting on top what whatever black-and-white
> distinctions are required to satisfy the formal DMTF model.
>
> interesting... good points... :-)
>
> - Gareth
>
> Dr. Gareth S. Bestor
> IBM Linux Technology Center
> M/S DES2-01
> 15300 SW Koll Parkway, Beaverton, OR 97006
> 503-578-3186, T/L 775-3186, Fax 503-578-3186
>
> [image removed] "Daniel P. Berrange" <berrange@redhat.com>
>

>
> "Daniel P. Berrange" <berrange@redhat.com>
> Sent by: xen-api-bounces@lists.xensource.com
> 09/14/06 02:47 PM
>
> Please respond to
> "Daniel P. Berrange" <berrange@redhat.com>
>
> [image removed]
> To
>
> [image removed]
> Jim Fehlig <jfehlig@novell.com>
>
> [image removed]
> cc
>
> [image removed]
> Xen-API <xen-api@lists.xensource.com>
>
> [image removed]
> Subject
>
> [image removed]
> Re: [Xen-API] New API Document and C Bindings
>
> [image removed]
>
> [image removed]
>
>
> On Thu, Sep 14, 2006 at 03:36:35PM -0600, Jim Fehlig wrote:
> > Ewan Mellor wrote:
> > >On Tue, Sep 12, 2006 at 07:16:40PM -0400, Stefan Berger wrote:
> > >
> > >
> > >>Also I have a question regarding domain-0. How will it be
represented? Is
> > >>it a VM - the fact that 'guest' is written in the description of the
VM
> > >>class makes me think that this might not be the case.
> > >>
> > >
> > >That's a very good question. My instinct is to say that dom-0
shouldn't
> > >be part of the list of domains, and that it should be considered part
of
> > >the infrastructure. When we have driver domains, and HVM stub
domains,
> > >there will be many of these domains, representing different parts of
the
> > >infrastructure, and it seems to me that these are not the same as
> > >"guests" or "VMs". A VM can be rebooted, migrated (possibly), each
time
> > >keeping the same VM, but ending up with a different domain. A VM is
> > >ultimately the reason that users are running Xen, and the thing that
> > >makes it useful. For this reason, I don't think that domain 0 is a
VM.
> > >
> > >On the other hand, these things are still useful entities -- you
might
> > >want to monitor the CPU cost due to each of them, tweak their
scheduling
> > >parameters, and so on. So perhaps they are close enough to being a
VM
> > >that we should put them in there, and cope with the slightly special
> > >nature of them as best we can.
> > >
> > >What do people think?
> > >
> >
> > Even though dom0 is part of the infrastructure (or as Gareth pointed
out
> > akin to a HMC), it still needs to be managed and many of the
management
> > functions are no different from 'normal' guests. VCPUs can be
> > hot-plugged and pinned to PCPUs, memory can be added / removed, etc.
> > From the perspective of adding / removing resources, dom0 is no
> > different than any other VM.
>
> I agree - having Dom0 represented in exactly same way as any other guest
> makes writing management apps very easy because we don't have to special
> case code. Sure there some operations you can't apply to Dom0 (such as
> suspend, migrate, etc), but equally there are some operations you can't
> apply to HVM guests (eg memory ballooning, suspend, migrate). There is
> plenty in common between Dom0 and other guests - which Jim lists here -
> which makes it a net win IMHO to treat Dom0 just like any other DomU.
>
> 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@lists.xensource.com
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
> [image removed] _______________________________________________
> xen-api mailing list
> xen-api@lists.xensource.com
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Thu, Sep 14, 2006 at 08:18:44PM -0400, Stefan Berger wrote:
> xen-api-bounces@lists.xensource.com 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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

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

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

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

On Fri, Sep 15, 2006 at 02:08:36AM +0100, John Levon wrote:
> 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.

I'm still not convinced that there's any particularly useful classification
of different domains. Each domain has a varying & overlapping set of
capabilities which can't easily be put into a strict hierarchy. Thus I
think it would be more useful to keep a flat classification of all domains,
and instead explicitly attach a set of capability flags to each domain. Apps
aren't really concerned with is this Domain type X, or Y - they are concerned
with what capabilities type X or Y has. Attaching capabilities directly to
individual domains is much more flexible than infering capabilities from
a 'type' approximation.

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

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 To
Sent by: John Levon <john.levon@sun.com>
xen-api-bounces@l cc
ists.xensource.co xen-api-bounces@lists.xensource.com
m , Xen-API
<xen-api@lists.xensource.com>
Subject
09/14/06 07:51 PM 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?

-Ron_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

I'm kinda leaning towards what Dan is thinking - right now Dom0 is
'special' only because it is the one Domain given administrative control of
all the host resources. But if this role is effectively farmed out to
future drive and stub domains, and this ability can be added arbitrarily to
*any* domain, then effectively any domain can assume the role of a
(partial) management domain at any time, so we're basically left with a
flat model - ie "all domains are created equal" :-)

- Gareth

Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186




"Daniel P.
Berrange"
<berrange@redhat. To
Sent by: cc
xen-api-bounces@l Xen-API
ists.xensource.co <xen-api@lists.xensource.com>,
m xen-api-bounces@lists.xensource.com
Subject
Re: [Xen-API] New API Document and
09/15/06 05:23 AM C Bindings


Please respond to
"Daniel P.
Berrange"
<berrange@redhat.






On Fri, Sep 15, 2006 at 02:08:36AM +0100, John Levon wrote:
> 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.

I'm still not convinced that there's any particularly useful classification
of different domains. Each domain has a varying & overlapping set of
capabilities which can't easily be put into a strict hierarchy. Thus I
think it would be more useful to keep a flat classification of all domains,
and instead explicitly attach a set of capability flags to each domain.
Apps
aren't really concerned with is this Domain type X, or Y - they are
concerned
with what capabilities type X or Y has. Attaching capabilities directly to
individual domains is much more flexible than infering capabilities from
a 'type' approximation.

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Gareth S Bestor/Beaverton/IBM wrote on 09/15/2006 09:57:44 AM:

> 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
>


You're correct to point out the differences between the CIM modeling goals
and the Xen API (thanks, at this early stage, I often confuse the two).

I guess I'm saying that the Xen API should not preclude such a direct
mapping from model -> implementation. In practical terms, this could
include the existence of multiple xend's (or equivalent) on a platform.
This could be for the parent -> child scenario I mentioned before, or it
could just be a high availability issue (e.g., sort of a dom0 hot
back-up). Granted, there's a lot of clever engineering needed to make any
of these scenarios a reality :-)

So in summary, I tend to agree more with John's and Dan's approach (but
I'd like to see some details in regard to the capabilities Dan mentions).

-Ron

Gareth Bestor wrote on 09/15/2006 10:04:46 AM:

> I'm kinda leaning towards what Dan is thinking - right now Dom0 is
'special' only
> because it is the one Domain given administrative control of all the
host
> resources. But if this role is effectively farmed out to future drive
and stub
> domains, and this ability can be added arbitrarily to *any* domain, then

> effectively any domain can assume the role of a (partial) management
domain at any
> time, so we're basically left with a flat model - ie "all domains are
created equal" :-)
>
> - Gareth
>

I don't think Dan and John are as far apart as Ewan's first proposal and
Dan's/John's proposals. I think Dan and John are saying the same thing,
but probably in two different languages / from two different perspectives.

If I'm wrong, someone please clarify the differences between Dan's and
John's proposals from both a CIM and Xen API standpoint.

Thanks,
-Ron

On Fri, Sep 15, 2006 at 10:13:45AM -0400, Ronald Perez wrote:
> Gareth Bestor wrote on 09/15/2006 10:04:46 AM:
>
> > I'm kinda leaning towards what Dan is thinking - right now Dom0 is
> 'special' only
> > because it is the one Domain given administrative control of all the
> host
> > resources. But if this role is effectively farmed out to future drive
> and stub
> > domains, and this ability can be added arbitrarily to *any* domain, then
>
> > effectively any domain can assume the role of a (partial) management
> domain at any
> > time, so we're basically left with a flat model - ie "all domains are
> created equal" :-)
> >
> > - Gareth
> >
>
> I don't think Dan and John are as far apart as Ewan's first proposal and
> Dan's/John's proposals. I think Dan and John are saying the same thing,
> but probably in two different languages / from two different perspectives.

We're both basically talking about how you represent the different
capabilities of domains. John is talking in terms of a hierarchy of
classes, where one class is a sub-set of the other. I'm talking in
terms of overlapping sets which is a more general representation.

Fundamentally the important thing we all agree on is the need for a
way of expressing the differing capabilities of domains.

> If I'm wrong, someone please clarify the differences between Dan's and
> John's proposals from both a CIM and Xen API standpoint.

We are primarily talking about how to express things in the Xen API - this
does not have to match how its expressed in CIM (provided we expose enough
information in Xen API for CIM to doing a suitable re-mapping). For example
in the Xen API we can express all domains the same way, but that doesn't
stop CIM expressing Domain-0 in a special Host class, seprate from other
guest VMs if that's appropriate for the CIM model.

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Fri, Sep 15, 2006 at 10:07:56AM -0400, Ronald Perez wrote:
> Gareth S Bestor/Beaverton/IBM wrote on 09/15/2006 09:57:44 AM:
>
> > 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
> >
>
>
> You're correct to point out the differences between the CIM modeling goals
> and the Xen API (thanks, at this early stage, I often confuse the two).
>
> I guess I'm saying that the Xen API should not preclude such a direct
> mapping from model -> implementation. In practical terms, this could
> include the existence of multiple xend's (or equivalent) on a platform.
> This could be for the parent -> child scenario I mentioned before, or it
> could just be a high availability issue (e.g., sort of a dom0 hot
> back-up). Granted, there's a lot of clever engineering needed to make any
> of these scenarios a reality :-)
>
> So in summary, I tend to agree more with John's and Dan's approach (but
> I'd like to see some details in regard to the capabilities Dan mentions).

That's the $1,000,000 question :-) Just what capabilities do we need to
represent to meet the needs of management applications using the API ?
So far this thread has mentioned what lifecycle states are possible for
a given domain, and what resource adjustments can be made to a domain.
Its probably unrealistic to come up with a complete set ahead of time, so
we probably need an initial basic set which is expanded over time.

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

"Daniel P. Berrange" <berrange@redhat.com> wrote on 09/15/2006 10:32:33
AM:
> On Fri, Sep 15, 2006 at 10:13:45AM -0400, Ronald Perez wrote:
>
> We're both basically talking about how you represent the different
> capabilities of domains. John is talking in terms of a hierarchy of
> classes, where one class is a sub-set of the other. I'm talking in
> terms of overlapping sets which is a more general representation.
>
> Fundamentally the important thing we all agree on is the need for a
> way of expressing the differing capabilities of domains.
>
> > If I'm wrong, someone please clarify the differences between Dan's and

> > John's proposals from both a CIM and Xen API standpoint.
>
> We are primarily talking about how to express things in the Xen API -
this
> does not have to match how its expressed in CIM (provided we expose
enough
> information in Xen API for CIM to doing a suitable re-mapping). For
example
> in the Xen API we can express all domains the same way, but that doesn't
> stop CIM expressing Domain-0 in a special Host class, seprate from other
> guest VMs if that's appropriate for the CIM model.
>
> Dan.

Thanks. So if John's "class hierarchy" were really a recursive
representation (as mentioned previously), that would be equivalent to your
"overlapping sets"? e.g., host_CPUs == VCPUs on a domU.

How do you envision capabilities being represented? By the presence or
absence of a field/feature/method or a bitmap or ???

-Ron

>Its probably unrealistic to come up with a complete set ahead of time, so
>we probably need an initial basic set which is expanded over time.

Well, for what its worth, the wolf closest to *my* door is the DMTF System
Virtualization model... :-)

- Gareth

Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186




"Daniel P.
Berrange"
<berrange@redhat. To
cc
09/15/06 07:36 AM Gareth S
Bestor/Beaverton/IBM@IBMUS,
xen-api-bounces@lists.xensource.com
Please respond to , Xen-API
"Daniel P. <xen-api@lists.xensource.com>
Berrange" Subject
<berrange@redhat. Re: [Xen-API] New API Document and










On Fri, Sep 15, 2006 at 10:07:56AM -0400, Ronald Perez wrote:
> Gareth S Bestor/Beaverton/IBM wrote on 09/15/2006 09:57:44 AM:
>
> > 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
> >
>
>
> You're correct to point out the differences between the CIM modeling
goals
> and the Xen API (thanks, at this early stage, I often confuse the two).
>
> I guess I'm saying that the Xen API should not preclude such a direct
> mapping from model -> implementation. In practical terms, this could
> include the existence of multiple xend's (or equivalent) on a platform.
> This could be for the parent -> child scenario I mentioned before, or it
> could just be a high availability issue (e.g., sort of a dom0 hot
> back-up). Granted, there's a lot of clever engineering needed to make any

> of these scenarios a reality :-)
>
> So in summary, I tend to agree more with John's and Dan's approach (but
> I'd like to see some details in regard to the capabilities Dan mentions).

That's the $1,000,000 question :-) Just what capabilities do we need to
represent to meet the needs of management applications using the API ?
So far this thread has mentioned what lifecycle states are possible for
a given domain, and what resource adjustments can be made to a domain.
Its probably unrealistic to come up with a complete set ahead of time, so
we probably need an initial basic set which is expanded over time.

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
-=|

On Fri, Sep 15, 2006 at 10:48:53AM -0400, Ronald Perez wrote:
> "Daniel P. Berrange" <berrange@redhat.com> wrote on 09/15/2006 10:32:33
> AM:
> >
> > We are primarily talking about how to express things in the Xen API -
> this
> > does not have to match how its expressed in CIM (provided we expose
> enough
> > information in Xen API for CIM to doing a suitable re-mapping). For
> example
> > in the Xen API we can express all domains the same way, but that doesn't
> > stop CIM expressing Domain-0 in a special Host class, seprate from other
> > guest VMs if that's appropriate for the CIM model.
> >
> > Dan.
>
> Thanks. So if John's "class hierarchy" were really a recursive
> representation (as mentioned previously), that would be equivalent to your
> "overlapping sets"? e.g., host_CPUs == VCPUs on a domU.

No they are not equivalent. There are scenarios you can represent with
overlapping sets which you can't represent in a hierarchy. Consider
three sets A, B, C. A overlaps with B, B overlaps with C, and C overlaps
with A - there's no way to represent that as a hierarchy - hierarchies
can only represent directed, a-cyclic graphs - overlapping sets are
non-directional cyclic graphs.

> How do you envision capabilities being represented? By the presence or
> absence of a field/feature/method or a bitmap or ???

A set of flags perhaps. Depending on the type of capability was want to
represent, they're not all going to be associated directly with a domain.
Some like lifecycle states may be scoped to a domain object. Others
may be associated with sub-objects - for example a domain having privileged
access to a piece of hardware may be flags on their hardware specific object.

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Yup. Arbitrary domains serving up 'resources' for arbitrary other domains
would not map to a hierarchy, not without some strict limitations that
would probably be rather messy for Xen to enforce.

This potential functionality does not map particularly well to today's DMTF
model either, but that's not Xen-API's problem...

- Gareth

Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186




"Daniel P.
Berrange"
<berrange@redhat. To
cc
09/15/06 08:00 AM Gareth S
Bestor/Beaverton/IBM@IBMUS, Xen-API
<xen-api@lists.xensource.com>,
Please respond to xen-api-bounces@lists.xensource.com
"Daniel P. Subject
Berrange" Re: [Xen-API] New API Document and
<berrange@redhat. C Bindings









On Fri, Sep 15, 2006 at 10:48:53AM -0400, Ronald Perez wrote:
> "Daniel P. Berrange" <berrange@redhat.com> wrote on 09/15/2006 10:32:33
> AM:
> >
> > We are primarily talking about how to express things in the Xen API -
> this
> > does not have to match how its expressed in CIM (provided we expose
> enough
> > information in Xen API for CIM to doing a suitable re-mapping). For
> example
> > in the Xen API we can express all domains the same way, but that
doesn't
> > stop CIM expressing Domain-0 in a special Host class, seprate from
other
> > guest VMs if that's appropriate for the CIM model.
> >
> > Dan.
>
> Thanks. So if John's "class hierarchy" were really a recursive
> representation (as mentioned previously), that would be equivalent to
your
> "overlapping sets"? e.g., host_CPUs == VCPUs on a domU.

No they are not equivalent. There are scenarios you can represent with
overlapping sets which you can't represent in a hierarchy. Consider
three sets A, B, C. A overlaps with B, B overlaps with C, and C overlaps
with A - there's no way to represent that as a hierarchy - hierarchies
can only represent directed, a-cyclic graphs - overlapping sets are
non-directional cyclic graphs.

> How do you envision capabilities being represented? By the presence or
> absence of a field/feature/method or a bitmap or ???

A set of flags perhaps. Depending on the type of capability was want to
represent, they're not all going to be associated directly with a domain.
Some like lifecycle states may be scoped to a domain object. Others
may be associated with sub-objects - for example a domain having privileged
access to a piece of hardware may be flags on their hardware specific
object.

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
-=|