This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-API] Re: xen-api Digest, Vol 4, Issue 4

To: xen-api@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-API] Re: xen-api Digest, Vol 4, Issue 4
From: Ronald Perez <ronpz@xxxxxxxxxx>
Date: Thu, 14 Sep 2006 10:11:03 -0400
Delivery-date: Thu, 14 Sep 2006 07:11:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <E1GNptQ-0000gj-6O@host-192-168-0-1-bcn-london>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

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

I think there are other ways to denote infrastructure VMs, or any other special VMs. They don't all have to be managed by the same guest VM management software/infrastructure -- e.g., there could be an infrastructure management control plane, or as we in the security space might call it, a security/trust domain consisting a set of VMs distributed among many platforms that just happen to be used for platform management. While these management VMs might not be migratable, you might still want to manage them as you suggested, as well as managing hot back-ups/clones, etc.

In the future when there are multiple dom-0's, or rather dom-0 is disaggregated, there may still be only one with the designation of "host".

xen-api mailing list
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-API] Re: xen-api Digest, Vol 4, Issue 4, Ronald Perez <=