Installing Xen Project Hypervisor on Debian 9: An in-depth beginner’s guide

Table of Contents:

  1. Installing the Debian base operating system
  2. Installing the Xen hypervisor and control domain (“Dom0”)
  3. Installing a guest domain (“DomU”)

The purpose of this tutorial is to describe how to install and configure a Xen Project hypervisor with control and guest domains using Debian as the base operating system. Note that this tutorial uses Xen version 4.8.5-pre as included in the current stable release of Debian 9 (Stretch).

Hardware

Concerning hardware, a Lenovo ThinkCentre M83 SFF Pro desktop computer was used to test this tutorial with the following main components:

  • Intel Core i5-4570 processor (4 cores),
  • 8GB DDR3 memory,
  • 120GB SSD,
  • 500GB HDD, and
  • Gigabit Ethernet port (with Internet connectivity).

Three-step process

Before we dive into the tutorial below, here’s a quick tip. It’s helpful to think of the Xen system installation as a three-step process made up of the following:

  1. installing the Debian base operating system,
  2. installing the Xen hypervisor and control domain (“Dom0“), and
  3. installing guest domains (“DomU“).

For the uninitiated, the term “domain” is used in Xen parlance to refer to a specific virtual machine or instance.

Xen background

The Xen hypervisor runs directly on the computer hardware, as such it is a Type 1 or “bare metal” hypervisor. The control domain, Dom0, is a privileged virtual machine that runs on top of the hypervisor, from where the user may create and control unprivileged guest domains, or DomU. In a typical Xen setup, a DomU operating system only knows about itself and cannot directly control the hypervisor, control domain, or any other guest domains.

Concerning the hypervisor’s relationship to Dom0 and DomU virtual machines, the most important points to remember are:

  • all domains (Dom0/DomU) are separate entities from the hypervisor,
  • all domains are virtual machines running on top of the hypervisor,
  • Dom0 is a privileged domain (may control DomU) and DomU are unprivileged domains (may only control itself), and
  • DomU may be either paravirtualized (“PV”), hardware virtual machines (“HVM”), or a mixture thereof.

It’s also good to know that the Xen installation process has been drastically simplified over the years through the hard work of dedicated individuals in the free open source software community. In fact, the installation process has been simplified to such an extent that many old Xen tutorials and books have you doing things that are either automatically configured today, or are no longer applicable in current kernel or operating system versions. Hopefully this tutorial helps to sort out, summarize, and explain some of the less-documented instructions, and also provides a bit more background and reference resources where necessary.

Alright, better get started! A detailed explanation of each installation step is provided below with links to additional reference material found throughout the tutorial.


STEP 1 – Installing the Debian base operating system

During the Xen installation process, the Debian base operating system is used to install and configure the Xen hypervisor and Dom0 virtual machine only. After Xen is installed and configured, GRUB is used to boot directly into the Xen hypervisor and Dom0 operating system where DomU can then be installed and configured.

For more information on how Xen’s various pieces fit together, check out the Xen Project Software Overview (sections “What is the Xen Project Hypervisor?” and “Introduction to Xen Project Architecture”), and Xen Project Beginner’s Guide (sections “What is this Xen Project software all about?” and “A brief look at Xen Project architecture”).

1.1 Download the Debian .iso

For this tutorial, a “network install” or “netinst” image of the current stable release, Stretch, can be downloaded from Debian’s website, debian.org. Choose the appropriate .iso for your computer’s architecture.

Once downloaded, the ~300MB “debian-9.5.0-amd64-netinst.iso” image can be written to an appropriately sized USB thumb drive using “dd”, the GNU coreutils program. Note that there are many detailed references available online describing how to safely write an operating system image to a USB drive using dd. For my goto dd reference, refer to the instructions provided on raspberrypi.org. Similar instructions may be found on debian.org.

CAUTION! If “dd” is run incorrectly it can wipe out your entire HDD – ensure that you have properly identified your USB thumb drive as detailed below, and that you have removed all files from the USB drive that you wish to keep.

1.2 Determine the USB drive name and unmount the drive

Before running the “dd” command, identify the device and partition name(s) on the USB drive using “lsblk”. Run lsblk first with the USB drive removed, then once again with the drive plugged in. The name that appears when the USB device is plugged in – for example, “sdx” – is, therefore, the USB drive.

$ lsblk

Once the USB drive has been positively identified as “sdx”, with a single partition of “sdx1”, unmount the partition by running the “umount” command as root user:

# umount /dev/sdx1

[N.B. Substitute your USB drive’s partition instead of “sdx1”.]

Note that your device may have more than one partition (e.g., sdx1 and sdx2). Run the “umount” command to unmount all mounted partitions on your USB drive.

1.3 Copy the .iso file to the USB drive using dd

“dd” can then be used to write the .iso image to the unmounted USB drive by running the following command as root user:

# dd bs=4M if=debian-9.5.0-amd64-netinst.iso of=/dev/sdx

[N.B. Substitute your USB drive’s name instead of “sdx”. Note that the command uses the device name not partition. Also, the name of the .iso file you download should follow the “if=” statement.]

Finally, run the “sync” command to ensure that it’s safe to remove the USB drive.

$ sync

1.4 Run Debian installer and partition the primary disk drive

Once the USB drive is loaded with the .iso, boot the computer with the USB drive plugged in to initiate the Debian installer. Make sure the computer’s BIOS is configured to boot from the USB drive ahead of the system’s disk drive(s).

Follow the Debian installer’s prompts setting up networking and user accounts as necessary. When the installer’s partition configuration section is reached choose the “manual” option, and setup the primary disk drive partitions as follows:

  • 4GB primary partition, filesystem type “ext4”, mark as “bootable”, mount on “/”
  • 1GB swap partition
  • with the remaining disk space, create a Volume Group partition with the name “vg0” (do not create a Logical Volume, and do not create a mount point)

[N.B. The primary disk on the test computer, “sda”, is a 120GB SSD.]

For more information on how to use the Debian installer for partition configuration, refer to the Debian GNU/Linux Installation Guide or chapter “4.2.13.2 Manual Partitioning” in the Debian Administrator’s Handbook.

To give context to the partition choices above, note that the minimal install of Debian 9.5 – with SSH server and standard system utilities installed, and no desktop environment – used 836MB of the 4GB primary partition, “sda1”, on the test computer. Even with packages “xen-system-amd64” and “xen-tools” installed, which we’ll be using later on, primary partition usage came in at only 1.1GB.

Similarly, after booting into the Debian base operating system, the “free” command registered only 61MB of memory usage. This is informative for determining the swap partition size. For most Xen system setups, the hypervisor and Dom0 do not require large amounts of disk space or memory, so create your partitions with this in mind.

As we have no need for a Xen hypervisor/Dom0 desktop environment, none was installed; however, SSH server and standard system utilities were installed by default.

Let the Debian installer finish and boot into the newly installed Debian base operating system.

[N.B. The secondary disk drive on the test computer, a 500GB HDD, was left untouched during the Debian installer process as it was previously formatted with a single ext4 filesystem partition, “sdb1”. Step 3, below, will illustrate how to provide access to and mount this drive in a DomU.]


STEP 2 – Installing the Xen hypervisor and control domain (“Dom0”)

The next step consists of installing the Xen hypervisor, and configuring the Dom0 virtual machine through the Debian base operating system. Once all preliminary configuration is complete, we will boot into the Xen hypervisor/Dom0 virtual machine to explore the new system.

Note that all code provided in Step 2 may be executed (1) via a SSH session, or (2) with a monitor connected to the Debian base operating system computer. However, once Xen is installed, the computer will be configured to boot directly into the Xen hypervisor/Dom0: Xen will be the GRUB default. In that case, if you would like to get back into the Debian base operating system once Xen is installed, connect a monitor to view and adjust the boot selection on the GRUB menu.

[N.B. If a monitor is not easily accessible, you can temporarily change the GRUB default to the Debian base operating system, then change it back to the Xen hypervisor/Dom0 when you’re done. One way to do this is by changing the name of the GRUB/Xen configuration file from “/etc/default/grub.d/xen.cfg” to “/etc/default/grub.d/xen.cfg.disabled”, then run “update-grub”. When you’re ready to have Xen as the GRUB default again, just rename the file “xen.cfg”. Remember to run the command “update-grub” after each configuration change otherwise it won’t take effect!]

2.1 Verify the system’s configuration

Verify the base operating system’s partition configuration by running the command “lsblk”:

$ lsblk

If the tutorial’s partition scheme for the base operating system was followed, the command will generate the following output:

xen1

The example output, above, includes the following configurations on the primary disk, “sda”:

  • a 4GB “sda1” partition with mount point “/”, showing up as 3.7G on the test computer,
  • a 1GB “sda2” swap partition with mount point “[swap]”, showing up as 954M on the test computer, and
  • the remaining disk space of 107.1G on “sda5” with no mount point.

To get more information on the Volume Group partition, “sda5”, created during the Debian installation process, run the “vgs” command as root user:

# vgs

This generates the following output on the test computer:

xen2

If there is a Volume Group configured – as there should be – then its Volume Group name (e.g., “vg0”) will be listed under the column header “VG”.

If something went wrong, lookup the commands “pvcreate” and “vgcreate” in the man pages, and review the section “Add LVM (Logical Volume Manager)” in the xmodulo.com Xen tutorial.

To create the LVM Volume Group, run the following two commands as root user substituting “sdax” with your desired Volume Group partition:

# pvcreate /dev/sdax
# vgcreate vg0 /dev/sdax

Now verify that the Volume Group was properly configured by running “vgs” as root user, as previously described above.

[N.B. The Volume Group is required in Step 3 to create partitions for the DomU virtual machine. Note that the recommended method for allocating disk and swap partitions to virtual machines in Xen is through the creation of Logical Volumes in a Volume Group.]

2.2 Install Xen hypervisor

Use “apt-get” to update the Debian base operating system package index files, and upgrade all currently installed packages. As root user run the following command:

# apt-get update && apt-get upgrade

Next, use “apt-get” to install the Xen meta-package. Run the following command as root user, adjusting the architecture suffix to suit your hardware:

# apt-get install xen-system-amd64

[N.B. The Debian Stretch repository provides three architecture options: amd64, arm64, and armhf. As the test computer has an Intel Core i5, this tutorial uses amd64 as an example.]

2.3 Verify GRUB’s menu default

Installing the “xen-system-amd64” package should automatically update the GRUB menu default; however, it is good form to take a moment and verify the configuration.

View the GRUB/Xen configuration file “/etc/default/grub.d/xen.cfg” using “less” by running the following command:

$ less /etc/default/grub.d/xen.cfg

Look for the comments and code located at the end of the file that match the following:

xen3

At the top of the same file the following line of code should be, by default, commented out:

#XEN_OVERRIDE_GRUB_DEFAULT=0

Note that the above code configures GRUB to boot into the Xen hypervisor/Dom0 virtual machine by default. If this code or configuration is missing from your system, copy the example code provided above into your “/etc/default/grub.d/xen.cfg” file. For an alternative configuration method, refer to the section “Prioritise Booting Xen Over Native” in the debian.org Xen tutorial.

2.4 Bridge the network interface

The easiest way to provide DomU access to the computer’s Ethernet device is through a Linux Ethernet bridge to Dom0. In this tutorial, the Debian package bridge-utils is used to configure the bridge. The “bridge-utils” package should have been installed automatically when the “xen-system-amd64” meta-package was installed.

Verify that bridge-utils is installed in the operating system by running the command “dpkg -l” [lower-case L], and piping the output through “grep”:

$ dpkg -l | grep bridge-utils

If the program is installed, the output should look something like this:

ii bridge-utils 1.5-13+deb9u1 amd64 Utilities for configuring the Linux Ethernet bridge

Once it is confirmed that bridge-utils is installed, it’s time to configure the system’s network settings. For all the steps below, it’s good form to make backup copies of the original configuration files before modifying them.

As root user, make a copy of the file “/etc/network/interfaces”:

# cp /etc/network/interfaces /etc/network/interfaces.backup

Now edit the “interfaces” file using the “nano” file editor:

# nano /etc/network/interfaces

The interfaces file on the test computer contains the following lines by default:

xen4

Note that the primary network interface in your computer may have a different name than “eno1”. Always use the name found in your computer’s “interfaces” file. In other words, don’t use “eno1” unless it’s the name found on your system.

Edit the “interfaces” file to include the following modifications and new lines making sure to substitute “eno1” with your system’s interface name:

xen5

[N.B. In “nano”, use “CTRL + O” to save, and “CRTL + X” to exit.]

It is important to set the primary network interface to “manual” and the bridge to “dhcp”, if you want to have your networking configured via DHCP. Also, note that “xenbr0” is the standard name used for the Linux Ethernet bridge in Xen installations.

Once the “interfaces” file is properly configured and saved, restart the systemd networking unit with the following command, executed as root user:

# systemctl restart networking

Then check that the bridge is properly configured by running the “ip addr” command, looking for mention of “xenbr0”:

$ ip addr

Running this command on the test computer produces the following output:

xen6

You can also check that the bridge and Ethernet device are properly associated by running the command “brctl show” as root:

# brctl show

Running this command on the test computer produces the following output:

xen7

For more information on configuring a Linux Ethernet bridge, setting up networking with a static ip address, or any other Xen networking options, review the following pages on wiki.xenproject.org (listed in order of complexity):

Debian also provides detailed network and bridge configuration information on their website:

2.5 Autoballoon and memory allocation

According to the Xen Project guides Tuning Xen for Performance and Xen Project Best Practices, it’s best to disable Xen’s “autoballoon” feature and allocate a set amount of memory to Dom0 for the following two reasons:

  • as the Linux kernel calculates various network related parameters based on the amount of memory detected at boot, these parameters could potentially be incorrect if memory allocation changes after boot, and
  • memory meta-data is created based on the amount of memory detected at boot; therefore, RAM is wastefully filled up with meta-data for memory that is not longer available to the system.

Note that 1GB of swap space was allocated during the Debian base operating system’s partitioning process. For the same reasons as provided in Section 1.4, above, 1GB of memory will be allocated to the Dom0 virtual machine. To ensure this allocation is properly carried out, three Xen configuration files must be modified to set Dom0’s memory limit and disable the “autoballoon” feature.

2.5.1 Edit /etc/xen/xl.conf

As root user, create a backup copy of file “/etc/xen/xl.conf”:

# cp /etc/xen/xl.conf /etc/xen/xl.conf.backup

Then open the “xl.conf” file in nano, and look for the commented-out line “#autoballoon=”auto””.

# nano /etc/xen/xl.conf

Delete the “#” character and change “”auto”” to “0”, so the line shows “autoballoon=0”. On the test computer, the modified file now reads:

xen8

Save the changes and exit the text editor.

[N.B. Note that it does not appear to affect the configuration if the zero is surrounded in quotes or not, for example, “0” versus 0.]

2.5.2 Edit /etc/xen/xend-config.sxp

As root user, create a backup copy of file “/etc/xen/xend-config.sxp”:

# cp /etc/xen/xend-config.sxp /etc/xen/xend-config.sxp.backup

Then open the “xend-config.sxp” file in nano, and look for the lines:

(dom0-min-mem 196)
(enable-dom0-ballooning yes)

Change these lines to:

(dom0-min-mem 1024)
(enable-dom0-ballooning no)

On the test computer, the sections that contained these lines now read:

xen9

Save the changes and exit the text editor.

2.5.3 Edit /etc/default/grub.d/xen.cfg

As root user, create a backup copy of file “/etc/default/grub.d/xen.cfg”:

# cp /etc/default/grub.d/xen.cfg /etc/default/grub.d/xen.cfg.backup

Then open the “xen.cfg” file in nano and add the line:

GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024M,max:1024M"

The modified “xen.cfg” file on the test computer now reads:

xen10

Save the changes and exit the text editor.

[N.B. I had some issues at this point in the configuration process. In hindsight, I realize I was confused when I compared the syntax used in other Xen tutorials to the example in the “xen.cfg” file provided on the test computer. The main confusion was concerning whether a space was permitted after the comma, and whether I should be using “max=1024M” versus “max:1024M”.

Even with the example “dom0_mem=[M]:max=[M]” provided in the “xen.cfg” file on the test computer, the syntax “”dom0_mem=1024M,max:1024M”” is what worked in the end.]

IMPORTANT! You must update GRUB or the changes will not take effect.

To update GRUB run the following command as root user:

# update-grub

2.6 Allocate Dom0 virtual CPUs

As the test computer only has four cores in its processor, no configuration was made to allocate CPUs to Dom0. By default, Xen makes all processor cores available to Dom0, who then shares these cores with DomU when the virtual machines are created (see below on how to allocate cores to DomU). This configuration is in line with the Xen Project guide Tuning Xen for Performance, which states under the “Dom0 vCPUs” section that “In general you should not assigned less than 4 vCPUs to Dom0”.

For more specific information on allocating vCPUs in your Xen system, refer to the following guides:

2.7 Disable domain saving and restoring

As mentioned in section “Configure guest behaviour on host reboot” of the Xen – Debian Wiki guide, it is a good idea to configure how DomU responds when Dom0 shuts down or reboots. Applying the configuration below ensures that Dom0 will not try to save or hibernate guest virtual machines when shutting down, which may have unforeseen consequences.

The configuration is made in the file “/etc/default/xendomains”. Make a backup copy of the file before modifying it. As root user, run the following command:

# cp /etc/default/xendomains /etc/default/xendomains.backup

Then open the “xendomains” file using “nano” and replace,

XENDOMAINS_SAVE=/var/lib/xen/save
XENDOMAINS_RESTORE=true

with the lines:

XENDOMAINS_SAVE=
XENDOMAINS_RESTORE=false

The “/etc/default/xendomains” file on the test computer now reads:

xen11

Save the changes and exit “nano”.

Restart the computer and boot into the Xen hypervisor/Dom0 virtual machine.

All configuration in the Debian base operating system is complete. Once you are ready, run the “reboot” command as root user:

# reboot

2.8 Boot into the Xen hypervisor/Dom0 and snoop around

If you have a monitor plugged in, after the computer reboots, you will see the GRUB menu with “Debian GNU/Linux, with Xen hypervisor” set as default. This is your new Xen hypervisor/Dom0 installation, and our current destination.

If you’re using SSH on a headless system, you’ll have to wait until the computer passes the GRUB menu, and loads the Xen hypervisor/Dom0 activating the SSH server daemon. Note that if the SSH server was enabled in the Debian base operating system, it will be enabled in the Xen hypervisor/Dom0.

Whether proceeding with or without a monitor, once you reach the familiar terminal login screen, use your login and password from the Debian base operating system to login to the new Xen hypervisor/Dom0 virtual machine.

Now that you’re in Dom0, check your work to make sure that all configurations made in the Debian base operating system were passed on to Dom0. Start by running the “free” command to verify that Dom0 has been allocated its 1GB of memory:

$ free -h

This results in the following output in the Dom0 virtual machine on the test computer:

xen12

Running “top” will also provide verification that Dom0 has been properly allocated memory:

$ top

Here is line four and five of top’s output when run on the test computer:

xen13

[N.B. Use the “q” key to quit top.]

While “free” and “top” are useful native GNU/Linux programs, the Xen management tool xl is essential while navigating Dom0 and examining other virtual machines. Note that “xl” must always be run as root, otherwise “bash” will complain: “command not found”.

2.8.1 xl list

Run the command “xl list”, which lists all currently running Xen virtual machines along with select operating and configuration information:

# xl list

The test computer produces the following output:

xen14

The output can be interpreted as,

There is one virtual machine running named Domain-0, which has the following characteristics:

  • its ID is 0 (Dom0’s ID is always 0),
  • it has been assigned 1024MB of memory,
  • it has the use of 4 virtual CPUs,
  • its current state is “r” or “running”, and
  • it has used 3.7 seconds of CPU time.

Specific information on “xl list” – and “xl” in general – can be found at xenbits.xen.org or by running the command “man xl”.

2.8.2 xl top

The command “xl top” also provides detailed information on currently loaded Xen virtual machines:

# xl top

This results in the following output on the test machine (for practical reasons, the output of “xl top” was truncated in this example):

xen15

From the output generated in the above commands, it appears that the configuration of memory, max memory, and vCPUs to Dom0 was successful.

[N.B. If you would like to verify network and bridge configuration in Dom0, refer to Section 2.4, above, for discussion of the commands “ip addr” and “brctl show”. These commands are available in Dom0, as they were in the Debian base operating system.]


STEP 3 – Installing a guest domain (“DomU”)

Now that the Xen hypervisor/Dom0 virtual machine is configured and up and running, it’s time to configure and create a DomU. For the purpose of this tutorial, the new DomU virtual machine will be configured with the intent of turning it into a FTP server for users on the local network. For simplicity sake, the DomU will be setup to run Debian 9 Stretch with a 4GB primary disk image, 1024MB swap partition, and 1024MB of allocated memory. DomU will also be given access to the 500GB HDD on the test computer (“sdb”), and its networking configuration will be set to DHCP.

The Debian package “xen-tools” will be used to configure and create the new DomU virtual machine. By default, xen-tools will also configure DomU’s networking and setup OpenSSH.

3.1 Install Debian package xen-tools

Use “apt-get” to update the Xen hypervisor/Dom0 package index files, and upgrade all currently installed packages. As root user run the following command:

# apt-get update && apt-get upgrade

Next, use apt-get to install the xen-tools package from the Debian Stretch repository, which is currently shipping xen-tools version 4.7-1. Run the following command as root user:

# apt-get install xen-tools

3.2 Review xen-tools default values in “xen-tools.conf” and the xen-create-image manual

Once “xen-tools” is installed, review the program’s documentation and configuration files to get a better understanding of its functionality. Many of the default DomU image creation settings for xen-tools are located in the file “/etc/xen-tools/xen-tools.conf”, which can be examined using the “less” command:

$ less /etc/xen-tools/xen-tools.conf

On the test computer, the following lines are uncommented in the “xen-tools.conf” file thereby making them the default values when creating DomU virtual machine images:

xen16

[N.B. The “/etc/xen-tools/xen-tools.conf” file on the test computer is 326 lines, so the uncommented lines listed above are only a small subset of all possible configuration.]

After reviewing the “xen-tools.conf” file, review the manual page for the xen-create-image command:

$ man xen-create-image

An extensive list of DomU configuration options are found in the manual page including additional default options concerning the allocation of VCPUs, e.g.,:

xen17

3.3 Test computer DomU configuration

For this tutorial, the following DomU configuration choices are accepted from the “xen-tools.conf” file:

  • install-method = debootstrap, the recommended Debian install-method;
  • fs = ext4, the recommended filesystem type for the Debian root partition;
  • ext4_options = noatime,nodiratime,errors=remount-ro, the default ext4 filesystem mount options [for more information refer to the manual pages “mount” and “fstab”];
  • kernel = /boot/vmlinuz-`uname -r`, the location of the kernel to be used in creating the DomU virtual machine. Note that this is Dom0’s kernel location; and,
  • initrd = /boot/initrd.img-`uname -r`, the location of the boot loader initialized RAM disk to be used in creating the DomU virtual machine. Note that this is Dom0’s “initrd.img” file location.

[N.B. Concerning the configuration image = sparse, the “xen-create-image” manual page explains: “Full images are mandatory when using LVM, so this setting is ignored in that case.” Therefore, as this tutorial is using LVM for its DomU disk allocation, the image= default configuration is not applicable.]

Additional configuration choices will be passed on the command line during DomU image creation, which include:

  • –hostname=ftpserver, the chosen hostname for the DomU (e.g., user@ftpserver);
  • –lvm=vg0, the name of the Volume Group from which to create the DomU “root disk” and “swap partitions”;
  • –dist=stretch, the GNU/Linux distribution and version to be installed on the DomU;
  • –size=4G, the size chosen for the root partition on the DomU. Note that this configuration is technically redundant as “xen-tools.conf” has the default set to 4G already;
  • –memory=1024M, the amount of memory to be allocated to the DomU at startup;
  • –maxmem=1024M, the maximum memory to ever be allocated to the DomU;
  • –swap=1024M, the swap partition size to be created for the DomU;
  • –pygrub, the DomU is to be booted using pygrub; and,
  • –dhcp, DomU networking will be configured via DHCP.

All other default DomU configuration options, not listed above, are accepted as outlined in the xen-create-image and xl.cfg manual pages. As mentioned above, since the default VCPU value is –vcpus=1, the new DomU will be assigned one virtual CPU at startup. Also, note that the default configuration for DomU “type” on x86 architecture is –type=”pv”, which means the virtual machine will be paravirtualized.

3.4 Create the DomU virtual machine image using xen-tools

Now that the DomU’s configuration has been established, it’s time to create the virtual machine image file. As root user, run the “xen-create-image” command to create the DomU virtual machine image and its corresponding Logical Volumes.

# xen-create-image --hostname=ftpserver --lvm=vg0 --dist=stretch --size=4G --memory=1024M --maxmem=1024M --swap=1024M --pygrub --dhcp

[N.B. The command above is one long line. If you don’t like long text in the command line, you can append backslashes (“\”) to your command like so,

# xen-create-image \
> --hostname=ftpserver \
> --lvm=vg0 \
> --dist=stretch \
> --size=4G \
> --memory=1024M \
> --maxmem=1024M \
> --swap=1024M \
> --pygrub \
> --dhcp

…]

Running the “xen-create-image” command results in the following output on the test computer:

xen18

The DomU image creation process took just under 4 minutes on the test computer as it was the first time the xen-create-image program was run, and because the DomU required files to be downloaded from the Debian mirror website.

Note that the xen-create-image command only creates a “ftpserver.cfg” DomU image file in the “/etc/xen/” directory. To start the DomU, the “xl create” command must be run.

3.5 Review the newly created DomU .cfg file

Before starting the DomU, review the newly created configuration file “/etc/xen/ftpserver.cfg” using the “less” command:

$ less /etc/xen/ftpserver.cfg

The “ftpserver.cfg” file on the test computer contains the following lines:

xen19

Most configuration options found in the .cfg file should be familiar, including the bootloader, vcpus, memory, maxmem, name, and dhcp KEY=VALUE pairs.

Under the “Disk device(s)” section, we find the newly created Logical Volumes phy:/dev/vg0/ftpserver-disk and phy:/dev/vg0/ftpserver-swap, or partitions “xvda2” and “xvda1”, respectively. Note that “xvda2” has been auto-configured as the “root” partition, and “xvda1” as swap.

For “Networking”, on creation, the ftpserver DomU will have a virtual interface [“vif”] assigned the MAC address “00:16:3E:52:85:D6”. Note that DomU’s IP and MAC addresses will be different from Dom0’s.

Finally, under the “Behaviour” section, the DomU is provided instructions on how to respond when the virtual machine is told to power off, reboot, or crashes. Note that on_poweroff is synonymous with the systemd “shutdown” command, and on_reboot with the systemd “reboot” command.

As described in the xl.cfg manual, under the value destroy it states that destroy is used to “destroy the domain”, and that the value restart is used to “destroy the domain and immediately create a new domain with the same configuration”.

For more information on configurable options available in the “/etc/xen/ftpserver.cfg” file, refer to the xl.cfg manual page.

[N.B. It is important to differentiate the xl.cfg “on_poweroff=destroy” configuration from the “xl destroy {domain-id}” command as detailed in the “xl” manual. The xl.cfg “destroy” value is essentially equivalent to running the systemd “shutdown” command on DomU, which should cause the virtual machine to shutdown gracefully. Contrast this with the “xl destroy {domain-id}” command in the “xl” manual where the value “destroy” has the following description:

“Immediately terminate the domain specified by domain-id. This doesn’t give the domain OS any chance to react, and is the equivalent of ripping the power cord out on a physical machine. In most cases you will want to use the shutdown command instead.”

The better way to shutdown or reboot DomU from the Dom0 console is with the “xl shutdown {domain-id}” or “xl reboot {domain-id}” commands, which are equivalent to DomU running the systemd “shutdown” or “reboot” commands from its own console.]

3.6 Confirm the creation of the DomU Logical Volumes

Take a moment to check that the “xen-create-image” command properly created the DomU’s Logical Volumes. The best way to do this is by using the “lsblk” command:

$ lsblk

On the test computer, this results in the following output:

xen20

From the above output, note that the swap and disk partitions have been successfully created as “vg0-ftpserver–swap” and “vg0-ftpserver–disk” on the “vg0” Volume Group.

As root user, running the “lvs” command will also provide detailed information about Dom0’s Logical Volumes:

# lvs

On the test computer, this results in the following output:

xen21

The output provides further confirmation that DomU’s Logical Volumes were successfully created by the “xen-create-image” command.

3.7 Configure DomU access to secondary disk (Part I)

If we were to start the DomU virtual machine now and run “lsblk” on its console, we would get the following output:

xen22

That is because DomU is only permitted to see the disks and partitions passed through its configuration file, “/etc/xen/ftpserver.cfg”, as specified under the “disk” heading:

xen23

Given the above configuration, the DomU cannot see the “sda” partitions of Dom0, nor can it see the secondary disk “sdb”. As the ftpserver DomU requires access to the 500GB HDD sdb1 partition, we must provide the proper configuration in the DomU’s .cfg file.

Before modifying the file, as root user, create a backup copy of “/etc/xen/ftpserver.cfg”:

# cp /etc/xen/ftpserver.cfg /etc/xen/ftpserver.cfg.backup

Next, use “nano” to modify the “/etc/xen/ftpserver.cfg” file so that the “disk” section now reads:

xen24

Note that only one virtual machine may have the partition mounted, which is why we did not create a mount point for the sdb1 partition in Dom0. Once we boot the DomU, we will login to the new virtual machine, create a mount point for sdb1, and configure the fstab file to auto-mount the partition.

Refer to the xl-disk-configuration manual page, available online, for more specific disk configuration information.

3.8 Start the new DomU

To start the new DomU virtual machine, use the “xl” Xen management tool to run the “xl create” command as root user, specifying the “ftpserver.cfg” DomU image file previously created:

# xl create /etc/xen/ftpserver.cfg

[N.B. Running the “xl create” command with the “-c” flag — for example, “xl create -c /etc/xen/ftpserver.cfg” — will cause the terminal window to be passed to the newly created DomU. Use the “CTRL + ]” key combination to exit the DomU terminal.]

Verify that the new “ftpserver” DomU virtual machine is running with the “xl list” command:

# xl list

The test computer generates the following output:

xen25

Similarly, running the “xl top” command on the test computer provides the following information (truncated for presentation purposes):

xen26

Access the new DomU’s console with the “xl console” command:

# xl console ftpserver

Login to the DomU as user “root” with the password generated during the “xen-create-image” process, e.g.,:

Root Password : AfkDDadUpcYP888MViTBNdZ

The password set during the DomU image creation process may also be found in the directory “/var/log/xen-tools/”, under the .log file associated with your chosen hostname. Of course, use the root password generated during your installation process.

3.9 Configure DomU access to secondary disk (Part II)

Running the “lsblk” command reveals that the “sdb1” partition, or virtual disk “xvda3”, has been successfully passed through to the DomU, but is not currently mounted:

$ lsblk

This generates the following output on the test computer:

xen27

The final task is to create a mount point for the partition, and ensure it auto-mounts on boot.

First, as root user, create a mount point for “xvda3” in the “/media/” directory. The mount point will be a directory called “WD_500GB”:

# mkdir /media/WD_500GB

Next, create a backup copy of the file “/etc/fstab”:

# cp /etc/fstab /etc/fstab.backup

Before modifying the “fstab” file, review the file’s contents with the “more” command:

# more /etc/fstab

[N.B. The ftpserver DomU did not have the “less” package installed by default. Using “more” or even “cat” is sufficient in this case, as the “fstab” file is not long.]

The test computer DomU generated the following output:

xen28

Now, use “nano” to add the following line to the “fstab” file:

xen29

DomU’s fstab should now read as follows:

xen30

Save the changes and exit nano. Now DomU is configured to mount the “xvda3” partition to the “/media/WD_500GB/” directory every time the virtual machine is started.

Run the “mount” command to mount all file systems specified in the fstab file:

# mount -a

Lastly, use the “lsblk” command to verify that all DomU partitions were successfully mounted:

# lsblk

DomU on the test computer generates the following output:

xen31

3.10 DomU statistics from free and df, and ip addr output

For those of you who are curious as to how much memory and disk space is used by the Debian Stretch DomU after installation, here is output generated from the “free” and “df” commands on the test computer:

$ free -h

xen32

$ df -h

xen33

Additionally, running the “ip addr” command in the DomU outputs the following:

xen34

A few more tips

Before we wrap up, here are a few navigational tips.

While in DomU’s console:

  • To shutdown the DomU, as root user run the command “shutdown -h now”
  • To reboot the DomU, as root user run the command “reboot”
  • To exit DomU’s console and go back to Dom0 use the “CTRL + ]” key combination

While in Dom0’s console:

  • To shutdown a DomU, as root user run the command “xl shutdown {domain-id}”
  • To reboot a DomU, as root user run the command “xl reboot {domain-id}”
  • To exit Dom0’s console and go back to DomU, as root user run the command “xl console {domain-id}”
  • To start a DomU for the first time, or to restart after shutdown, as root user run the “command xl create {full-location-to-DomU .cfg file}”

[N.B. If it appears you are in a frozen terminal in any one of the transitions above, try pressing ENTER again, and you will likely find out that you are not!]

It is important to note that the DomU operating system – like any “real” operating system – will retain all configuration history and file creation/destruction changes even after it is shutdown and restarted. Simply configure and use the DomU virtual machine as you would any operating system.

Final words

If you encounter issues during any of the installation or configuration stages described above, make sure to thoroughly review the manual pages and/or search for relevant websites or tutorials specific to your issue – sometimes this is easier said then done, as it can be hard to figure out exactly what is causing the problem. For all intents and purposes, the Xen Project’s wiki is an excellent source of information, as are the other websites I’ve linked to throughout the tutorial.

Here’s hoping that your Xen Project hypervisor installation went as smoothly as mine!

Now that everything is up and running, it’s time to decide which Debian repository FTP package to install…

A free PDF version of this tutorial is available here.