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

Re: [Xen-devel] Terminology for "guest" - Was: [PATCH] docs/sphinx: Introduction

On Aug 8, 2019, at 06:49, Jan Beulich <JBeulich@xxxxxxxx> wrote:

On 08.08.2019 11:13, Julien Grall wrote:
Hi Jan,

On 08/08/2019 10:04, Jan Beulich wrote:
On 08.08.2019 10:43, Andrew Cooper wrote:
On 08/08/2019 07:22, Jan Beulich wrote:
On 07.08.2019 21:41, Andrew Cooper wrote:
--- /dev/null
+++ b/docs/glossary.rst
@@ -0,0 +1,37 @@
+.. Terms should appear in alphabetical order
+.. glossary::
+   control domain
+     A :term:`domain`, commonly dom0, with the permission and
+     to create and manage other domains on the system.
+   domain
+     A domain is Xen's unit of resource ownership, and generally has
at the
+     minimum some RAM and virtual CPUs.
+     The terms :term:`domain` and :term:`guest` are commonly used
+     interchangeably, but they mean subtly different things.
+     A guest is a single virtual machine.
+     Consider the case of live migration where, for a period of
time, one
+     guest will be comprised of two domains, while it is in transit.
+   domid
+     The numeric identifier of a running :term:`domain`.  It is
unique to a
+     single instance of Xen, used as the identifier in various APIs,
and is
+     typically allocated sequentially from 0.
+   guest
+     See :term:`domain`

I think you want to mention the usual distinction here: Dom0 is,
while a domain, commonly not considered a guest.

To be honest, I had totally forgotten about that.  I guess now is the
proper time to rehash it in public.

I don't think the way it currently gets used has a clear or coherent set
of rules, because I can't think of any to describe how it does get used.

Either there are a clear and coherent (and simple!) set of rules for
what we mean by "guest", at which point they can live here in the
glossary, or the fuzzy way it is current used should cease.

What's fuzzy about Dom0 not being a guest (due to being a part of the
host instead)?
Dom0 is not part of the host if you are using an hardware domain.

It's still the control domain then, and hence still part of the host.

With disaggregation and dom0less (how might we describe that term in the intro?) for edge/embedded Xen systems, there could be a mode where the control domain has never had privilege over the domain that handles the physical TPM, or the provider of the virtual TPM:  

Xen-devel mailing list



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