Domain0
The hypervisor is not alone in its task of administering the guest domains on the system. A special privileged domain called Domain0 serves as an administrative interface to Xen. In a Xen system, Domain0 actually implements some of the functionality we described as being logically a function of the hypervisor. This allows the Xen hypervisor to be a thin layer.
Domain0 is the first domain launched when the system is booted, and it can be used to create and configure all other regular guest domains. Domain0 is also called Dom0 and, similarly, a regular guest domain is called a DomU or unprivileged domain.
Domain0 has direct physical access to all hardware, and it exports the simplified generic class devices to each DomU. Rather than emulating the actual physical devices exactly, the hypervisor exposes idealized devices. For example, the guest domain views the network card as a generic network class device or the disk as a generic block class device. Domain0 runs a device driver specific to each actual physical device and then communicates with other guest domains through an asynchronous shared memory transport.
Domain0 can also delegate responsibility for a particular device to another domain. A driver domain is a DomU that runs a minimal kernel and the backend for a particular device. This has the advantage of moving the complexity and risk of device management out of the Domain0. Moving device management to driver domains can make the system more stable because hardware drivers are notoriously the most error-prone code in an operating system. A driver domain could be stopped and restarted to recover from an error, while stopping and restarting Domain0 can disrupt the entire system.
The physical device driver running in Domain0 or a driver domain is called a backend, and each guest with access to the device runs a generic device frontend driver. The backends provide each frontend with the illusion of a generic device that is dedicated to that domain. The backend understands the details of the real physical device and packages the generic device requests from each frontend into the appropriate form for forwarding to the hardware. Backends also implement the sharing and multiple accesses required to give multiple guest domains the illusion of their own dedicated copy of the device. In general, a smaller and simpler Domain0 is better for the security and stability of the system. Moving device management into driver domains is just one example of this. Although Domain0 typically runs a general purpose operating system, it is wise to use Domain0 strictly for the administration of virtual machines on the system. It is highly recommended that you limit the user level code installed and running in Domain0 to only those applications that are essential to administration of the virtual machines on the system. All other applications can be run in a guest domain. Similarly, it is best to close all unnecessary network ports in Domain0. Overall, a bare-bones Domain0 is less vulnerable to attack or accidental software fault.
We summarize this comparison of Domain0, driver domains and regular guest domains in Table 3.1.
Table 3.1. Comparing Domain0, Driver Domains, and Regular Guest Domains
Type |
Privilege Level |
Software |
Purpose |
Domain0, Dom0 |
Privileged domain |
Bare-bones OS |
Controls physical hardware. |
Applications to create and configure other domains only or physical device access |
Used to create and configure other domains to other domains. |
||
Physical device drivers |
|||
Interface to allow other guests to access physical devices controlled |
|||
Driver domain |
Privileged domain |
Bare-bones OS |
Guest domain that is given physical access to a device for the purpose of sharing that device among other domains. |
Physical device drivers |
|||
Interface to allow other guests to access physical devices controlled |
|||
Throughout this book, we use the term Driver Domain to refer to a guest with physical access to the device hardware. Domain0 is often used for this purpose. Running device drivers in Domain0 is typically the simplest and most straightforward configuration. |
|||
Regular guest domain, DomU |
Unprivileged (by default) |
General-purpose OS |
Typically virtual device. |
User level applications access only; must run a frontend driver for multiplexed drivers shared with other domains. |
|||
May be granted direct physical access to a device, but best to avoid if possible. |