- control domain¶
A domain, commonly dom0, with the permission and responsibility to create and manage other domains on the system.
A domain is Xen’s unit of resource ownership, and generally has at the minimum some RAM and virtual CPUs.
A guest is a single, end user, virtual machine.
In some cases, e.g. during live migration, one guest will be comprised of two domains for a period of time, while it is in transit.
The numeric identifier of a running domain. It is unique to a single instance of Xen, used as the identifier in various APIs, and is typically allocated sequentially from 0.
The term ‘guest’ has two different meanings, depending on context, and should not be confused with domain.
When discussing a Xen system as a whole, a ‘guest’ refer to a virtual machine which is the “useful output” of running the system in the first place (e.g. an end-user VM). Virtual machines providing system services, (e.g. the control and/or hardware domains), are not considered guests in this context.
In the code, “guest context” and “guest state” is considered in terms of the CPU architecture, and contrasted against hypervisor context/state. In this case, it refers to all code running lower privilege privilege level the hypervisor. As such, it covers all domains, including ones providing system services.
- hardware domain¶
A domain, commonly dom0, which shares responsibility with Xen about the system as a whole.
By default it gets all devices, including all disks and network cards, so is responsible for multiplexing guest I/O.
- system domain¶
Abstractions within Xen that are modelled in a similar way to regular domains. E.g. When there’s no work to do, Xen schedules
DOMID_IDLEto put the CPU into a lower power state.
System domains have domids and are referenced by privileged software for certain control operations, but they do not run guest code.