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

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

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