Xen Project Hypervisor

The Xen Project Logo

The Xen Project Hypervisor is an open-source type-1 virtual machine manager, which allows multiple virtual machines, known as domains, to run concurrently with the host on the physical machine. This is unlike a typical type-2 hypervisor, such as QEMU, where the virtual machines run as applications on top of the host. NixOS runs as the privileged Domain 0, and can paravirtualise or fully virtualise Unprivileged Domains (domUs).

Xen is well-known for its impeccable security record, and is the go-to solution for hyper-scale cloud infrastructures.

Installation

Since NixOS 24.11, installing the Xen Hypervisor is as simple as adding the following to your NixOS configuration:

configuration.nix

{
  virtualisation.xen.enable = true;
}

Tip

In order to affect your NixOS system by your nix-language-specific changes you must first evaluate it:

$ nixos-rebuild boot --use-remote-sudo

Then, reboot:

$ systemctl reboot

After a successful reboot, you should now be using a Xen EFI kernel, and Xen's usual commands, such as xl, will begin working. Right after a fresh boot, there's usually only a single domain (virtual machine) running: the Domain 0.

About the Domain 0

The Domain 0, generically known as the host machine, is the most important virtual machine in a Xen system. It is responsible for orchestrating the Unprivileged Domains, and housing the Linux kernel version that interacts with the bare-metal hardware. Here, you can use libxenlight, Xen's main interface system, through the aforementioned xl command. See the manual page xl(1) for usage information.

An important security feature of Xen is the ability to disaggregate the responsibilities given to the Domain 0. While it will normally be responsible for hosting Xen's shared database, the Xen Store, this responsibility can instead be assigned to a stubdomain: a special type of lightweight Xen virtual machine that runs a Domain 0 function in an isolated and secure manner.

Domain 0 has special security considerations.

If the Domain 0 is compromised by an attacker, then the entire server running Xen should be considered compromised. It is recommended that the NixOS installation running in the host VM is kept as minimal and up-to-date as possible. Avoid packages with large attack surfaces, such as desktop environments, run every user-facing service in an unprivileged domain, and if you're under a lax firewall, consider denying network access to and from Domain 0.

Configuration

There are many options available for configuring the Domain 0. Here is a recommended non-default configuration:

configuration.nix

{
  virtualisation.xen = {
    enable = true;
    efi.bootBuilderVerbosity = "info"; # Adds a handy report that lets you know which Xen boot entries were created.
    bootParams = [
      "vga=ask" # Useful for non-headless systems with screens bigger than 640x480.
      "dom0=pvh" # Uses the PVH virtualisation mode for the Domain 0, instead of PV.
    ];
    dom0Resources = {
      memory = 1024; # Only allocates 1GiB of memory to the Domain 0, with the rest of the system memory being freely available to other domains.
      maxVCPUs = 2; # Allows the Domain 0 to use, at most, two CPU cores.
    };
  };
}

Some configurations may cause a system to become vulnerable to known security issues.

Some option combinations are known to cause security vulnerabilities that may be exploited to cause a denial of service attack. That said, the assertions system present in the Xen module will prevent you from evaluating a known-unsafe configuration.

Running VMs

Currently, unprivileged domains can only be created/destroyed imperatively. See the usual Xen documentation for more specific usage information. To get you started, here's an example Xen configuration file that can produce a fully virtualised domain:

example-hvm.cfg

name='example-domain'
memory='2048'
vcpus=2
type='hvm'
disk=[ '/path/to/where/you/want/to/store/the/virtual/disk.qcow2,qcow2,hda,w', 'file:/path/to/a/nixos-installation.iso,hdc:cdrom,r' ]
boot='cd'

See xl.cfg(5) for more configuration options.

You can then start the domain using the following command:

# xl create /path/to/example-hvm.cfg -Fc

If you are interested in managing Xen domains declaratively, please take a look at pull request #363388 and everything else tagged with the declarative libxenlight title.

Troubleshooting

`error: device model qemu-dm is not executable: No such file or directory`

This error follows a qemu-xen is unavailable, using qemu-xen-traditional instead message. This is an upstream bug in Xen, and can be fixed by pull request #365890, or by overriding the QEMU path in your domain configuration:

example-hvm.cfg

device_model_override='/run/current-system/sw/bin/qemu-system-i386'