[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.