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

[Gareth S Bestor <bestorga@xxxxxxxxxx>]

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@xxxxxxxxxxxxx>
Sent by: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

09/13/2006 10:23 PM

To	Stefan Berger/Watson/IBM@IBMUS
cc	Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
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@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