libvirt
Apart from using the recommended libvirt
library
(Part II, “Managing Virtual Machines with libvirt
”), you can manage Xen guest
domains with the xl
tool from the command line.
The xl
program is a tool for managing Xen guest
domains. It is part of the xen-tools package.
xl
is based on the LibXenlight library, and can be
used for general domain management, such as domain creation, listing,
pausing, or shutting down. Usually you need to be root
to
execute xl
commands.
xl
can only manage running guest domains specified by
their configuration file. If a guest domain is not running, you cannot
manage it with xl
.
To allow users to continue to have managed guest domains in the way the
obsolete xm
command allowed, we now recommend using
libvirt
's virsh
and
virt-manager
tools. For more information, see
Part II, “Managing Virtual Machines with libvirt
”.
xl
operations rely upon
xenstored
and
xenconsoled
services. Make sure you start
tux >
systemctl start xencommons
at boot time to initialize all the daemons required by
xl
.
xenbr0
Network Bridge in the Host Domain
In the most common network configuration, you need to set up a bridge in
the host domain named xenbr0
to have a
working network for the guest domains.
The basic structure of every xl
command is:
xl <subcommand> [options] domain_id
where <subcommand> is the xl command to run, domain_id is the ID
number assigned to a domain or the name of the virtual machine, and
OPTIONS
indicates subcommand-specific options.
For a complete list of the available xl
subcommands,
run xl help
. For each command, there is a more
detailed help available that is obtained with the extra parameter
--help
. More information about the respective
subcommands is available in the manual page of xl
.
For example, the xl list --help
displays all options
that are available to the list command. As an example, the xl
list
command displays the status of all virtual machines.
tux >
sudo
xl list Name ID Mem VCPUs State Time(s) Domain-0 0 457 2 r----- 2712.9 sles12 7 512 1 -b---- 16.3 opensuse 512 1 12.9
The r
(running) and b
(blocked) where
blocked means it is either waiting for IO, or sleeping because there is
nothing to do. For more details about the state flags, see man 1
xl
.
Other useful xl
commands include:
xl create
creates a virtual machine from a given
configuration file.
xl reboot
reboots a virtual machine.
xl destroy
immediately terminates a virtual machine.
xl block-list
displays all virtual block devices
attached to a virtual machine.
When operating domains, xl
requires a domain
configuration file for each domain. The default directory to store such
configuration files is /etc/xen/
.
A domain configuration file is a plain text file. It consists of
several
KEY=VALUE
pairs. Some keys are mandatory, some are general and apply to any
guest, and some apply only to a specific guest type (para or fully
virtualized). A value can either be a "string"
surrounded by single or double quotes, a number, a boolean value, or
a list of several values enclosed in brackets [ value1,
value2, ... ]
.
/etc/xen/sled12.cfg
#name= "sled12" builder = "hvm" vncviewer = 1 memory = 512 disk = [ '/var/lib/xen/images/sled12.raw,,hda', '/dev/cdrom,,hdc,cdrom' ] vif = [ 'mac=00:16:3e:5f:48:e4,model=rtl8139,bridge=br0' ] boot = "n"
To start such domain, run xl create
/etc/xen/sled12.cfg
.
To make a guest domain start automatically after the host system boots, follow these steps:
Create the domain configuration file if it does not exist, and save it
in the /etc/xen/
directory, for example
/etc/xen/domain_name.cfg
.
Make a symbolic link of the guest domain configuration file in the
auto/
subdirectory.
tux >
sudo
ln -s /etc/xen/domain_name.cfg /etc/xen/auto/domain_name.cfg
On the next system boot, the guest domain defined in
domain_name.cfg
will be started.
In the guest domain configuration file, you can define actions to be performed on a predefined set of events. For example, to tell the domain to restart itself after it is powered off, include the following line in its configuration file:
on_poweroff="restart"
A list of predefined events for a guest domain follows:
Specifies what should be done with the domain if it shuts itself down.
Action to take if the domain shuts down with a reason code requesting a reboot.
Action to take if the domain shuts down because of a Xen watchdog timeout.
Action to take if the domain crashes.
For these events, you can define one of the following actions:
Destroy the domain.
Destroy the domain and immediately create a new domain with the same configuration.
Rename the domain that terminated, and then immediately create a new domain with the same configuration as the original.
Keep the domain. It can be examined, and later destroyed with
xl destroy
.
Write a core dump of the domain to
/var/xen/dump/NAME
and then destroy the domain.
Write a core dump of the domain to
/var/xen/dump/NAME
and then restart the domain.
The Time Stamp Counter (TSC) may be specified for each domain in the guest domain configuration file (for more information, see Section 20.1.1, “Guest Domain Configuration File”).
With the tsc_mode
setting, you specify whether
rdtsc instructions are executed “natively” (fast, but
TSC-sensitive applications may sometimes run incorrectly) or emulated
(always run correctly, but performance may suffer).
tsc_mode=0
(default)Use this to ensure correctness while providing the best performance possible—for more information, see https://xenbits.xen.org/docs/4.3-testing/misc/tscmode.txt.
tsc_mode=1
(always emulate)Use this when TSC-sensitive apps are running and worst-case performance degradation is known and acceptable.
tsc_mode=2
(never emulate)Use this when all applications running in this VM are TSC-resilient and highest performance is required.
tsc_mode=3
(PVRDTSCP)High-TSC-frequency applications may be paravirtualized (modified) to obtain both correctness and highest performance—any unmodified applications must be TSC-resilient.
For background information, see https://xenbits.xen.org/docs/4.3-testing/misc/tscmode.txt.
Make sure the virtual machine to be saved is running.
In the host environment, enter
tux >
sudo
xl save ID STATE-FILE
where ID is the virtual machine ID you want
to save, and STATE-FILE is the name you
specify for the memory state file. By default, the domain will no
longer be running after you create its snapshot. Use
-c
to keep it running even after you create the
snapshot.
Make sure the virtual machine to be restored has not been started since you ran the save operation.
In the host environment, enter
tux >
sudo
xl restore STATE-FILE
where STATE-FILE is the previously saved
memory state file. By default, the domain will be running after it is
restored. To pause it after the restore, use -p
.
A virtual machine’s state can be displayed by viewing the results of
the xl list
command, which abbreviates the state using
a single character.
r
- running - The virtual machine is currently
running and consuming allocated resources.
b
- blocked - The virtual machine’s processor is
not running and not able to run. It is either waiting for I/O or has
stopped working.
p
- paused - The virtual machine is paused. It does
not interact with the hypervisor but still maintains its allocated
resources, such as memory.
s
- shutdown - The guest operating system is in the
process of being shut down, rebooted, or suspended, and the virtual
machine is being stopped.
c
- crashed - The virtual machine has crashed and is
not running.
d
- dying - The virtual machine is in the process of
shutting down or crashing.