configuration files for the domUs that you are creating can be placed
anywhere as long as you provide the full path to the file when creating
the domain. The
special directory and any domain configuration files that are placed in
this directory will automatically be started when the
Here are some of the common options specified in a Xen domain configuration file:
kernel: The kernel image that is used for the domain is provided as the complete path to the kernel image file.
Specifies the initial ramdisk for the domain. If your kernel has
built-in drivers for your root file system and hard disk, you may not
need to create and specify a ramdisk. This is provided as a complete
path to the location of the initrd file.
Specifies the amount of RAM, in megabytes, that is allocated for the
domain. Insufficient memory allocation will prevent the domain from
starting up. You must also ensure that the total memory taken by
Xen—both dom0 and all the domUs—must be less than or equal to the amount
of physical RAM present in your machine.
name: Provides a unique name to identify the domain. This name will be be displayed when you list the domains running on the system.
root: Specifies the root device for the domain.
disk: Specifies a list of block devices that is exported to the domain. This is provided in the following the format:
disk = [ "backend device", "frontend device", "mode" ]
The "backend device"
specifies the format and name of the device that will be exported to
the guest domain. The format can be a simple file image or an actual
physical disk. A file image is exported to the guest domain as a
file-based VBD by Xen.
file://path_to_the_file_image: The file image is exported as a loopback device. The setup of the loopback device is taken care of by Xen.
The file image is exported as a tap device that can be accessed by the
Xen blktap driver. This is specified as the suggested way in the Xen
documentation for exporting file images to the guest domain.
phy:device:/name_of_the_device: The specified physical device is exported to the guest domain. The device can be specified in the usual /dev/sda1 form or using the hex major/minor number for the device—0x301.
"frontend device" specifies how the exported backend device should
appear to the guest domain. This can be specified in the usual /dev/sda1
form or using the hex major/minor number for the device—0x301.
The "mode" specifies whether the device is to be exported as read-only or read‑write. The two valid options are:
rw—read and write.
vif: Specifies the virtual network interface configuration for the domain. This is provided in the following format:
vif = [ "key1 = value1", "key2 = value2" ]
The common options used for this configuration directive are:
bridge: Specifies the network bridge that will be used for this interface.
Specifies the MAC address for this virtual interface. If you do not
provide a MAC address, it is set to a random MAC address by Xen on boot.
The random address is selected from the range of addresses assigned to
Xensource by IEEE in the XenSource Organizationally Unique Identifier
(OUI) range 00-16-3E. You can also use this directive for defining a
static MAC address that will receive a static IP assignment from your
on_reboot: Specifies the action taken by the domain during a reboot. The valid states on a reboot are:
destroy: Completely shuts down the domain.
preserve: The domain is not cleaned up. The debugging information from the domain is available to help debug crashes.
rename-restart: The old domain is not cleaned up. Instead it is renamed and a new domain is started in place of the old domain.
Specifies the action taken by the domU if it crashes. The valid states
for this directive are the same as that for on_reboot option.
vcpus: The number of virtual CPUs.
The following figure shows
the domain configuration file for
creating and running the Ubuntu Feisty guest domain: