Contents
Graphical utilities, text-based commands, and modified configuration files are methods you can choose from to manage your virtualization environment.Virtual Machine Manager is a graphical utility available in YaST that can be launched from the virtual machine Domain0.
From a command line interface on the virtual machine host, you can use the vm-install and xm commands to create and manage virtual machines. You can also edit configuration files to change the settings of the virtual machine host or a virtual machine.
The YaST Virtual Machine Manager provides a graphical user interface you can use to create and manage virtual machines. This utility can be run either locally on the VM Host Server or remote. The connection is then secured either with an SSL/TLS with x509 certificate, or with a tunnel over SSH.
![]() | |
Close Virtual Machine Manager if you are not actively using it and restart it when needed. Closing Virtual Machine Manager does not affect the state of virtual machines. |
When starting the Virtual Machine Manager locally on the controlling Domain0, it is directly connected to the Xen managing demon. All locally managed domains are displayed and can be modified.
From remote, the Virtual Machine Manager can also be started as normal user without administrative rights. To start it, run the command virt-manager. If the local machine does not manage virtual domains, the Virtual Machine Manager first has to connect the managing domain of a Xen VM Host Server. To do this, use the following procedure:
Make sure that Domain0 on the VM Host Server accepts incoming SSH connections. If in doubt, run
+ + and make sure that is added to the .Run
+ .Select Xen at the
pull-down menu.Select
at the pull down menu.Enter the hostname of the controlling Domain0 into the
text field.Press
to initiate the connection.
On request, enter the password of the
root
user of the controlling
Domain0. This is not necessary when using SSH keys and configuring the
local user as authorized for
root
access on the
controlling Domain0.
When connected to a controlling Domain0, the Virtual Machine Manager offers several configuration possibilities.
Selec a virtual machine and click
to display the virtual machine window showing the virtual machine’s current state.Click
on the virtual machine window to boot the virtual machine and display the user interface or text console running on the virtual machine.Select a virtual machine and click
to let you view performance and configure hardware details associated with the virtual machine.Click Section 3.1, “Creating a Virtual Machine”. This option is only available when the Xen host is selected.
in Virtual Machine Manager to launch the , which walks you through the steps required to set up a virtual machine. See alsoThe Xend is a key component of Xen virtualization. It performs management functions and stores settings that relate to the host environment and each virtual machine. You can customize Xend to meet your specific configuration requirements.
Important services that must be configured in this file are:
Settings for live migrations, define migration hosts
Path to Xend lock
files. These can be used to
prevent Xen from starting a guest a second time on a migration host.
To specify Xend operating parameters, edit the
/etc/xen/xend-config.sxp
file. The settings take
effect the next time Xend starts.
# -*- sh -*- # # Xend configuration file. # # This example configuration is appropriate for an installation that # utilizes a bridged network configuration. Access to Xend via http # is disabled. # Commented out entries show the default for that entry, unless otherwise # specified. #(logfile /var/log/xen/xend.log) #(loglevel DEBUG) # The Xen-API server configuration. # # This value configures the ports, interfaces, and access controls for the # Xen-API server. Each entry in the list starts with either unix, or a port
To start the Xend daemon, enter rcxend start.
To stop the Xend daemon, enter rcxend stop.
To restart the Xend daemon, enter rcxend restart.
To check the status of the Xend daemon, enter rcxend status.
The parameters in the xend-config.sxp
file can be
customized to meet your requirements for virtualization. For a full list
of all available options, read the manual page of
xend-config.sxp
.
The machine settings of each virtual guest are stored in an internal database managed by xend. You can change a virtual machine’s settings by modifying the settings stored in Xend. This process requires you to export a virtual machine’s settings from the Xend database to a text file, edit the settings in the file to meet your configuration requirements, import the file back into Xend, and restart the virtual machine.
Some commonly used configurations can be done online with the xm command. These include the attachment or detachment of virtual block, network or PCI devices. For more details, see the manual page of xm.
![]() | |
It is no longer recommended that you edit the initial start-up files
stored in |
To modify a virtual machine’s settings that is administrated with the virtual machine manager, first shut it down and then:
At Domain0, enter
xm list -l vm_name
> filename
where vm_name
is the
name of the virtual machine you want to modify and
filename
is whatever you want to
name the text file.
Use a text editor to make and save any desired changes.
(domain (domid 1) (bootloader /usr/bin/pygrub) (on_crash destroy) (uuid aa6969f3-8012-24f0-1e3a-35f150001950) (bootloader_args -q) (vcpus 2) (name sles11) (cpus (() ())) (on_reboot restart) (on_poweroff destroy) (maxmem 512) (memory 512) (shadow_memory 0) (features ) (on_xend_start ignore) (on_xend_stop ignore) (start_time 1240210933.16) (cpu_time 35.841108115) (online_vcpus 2) ....
Delete the existing configuration from Xend with the command
xm del vm_name
Enter xm new -F filename
to import the virtual machine’s new settings into Xend.
Enter xm start vm_name
to start the virtual machine with its new settings.
You should repeat the entire process of exporting the file each time you want to make changes to a virtual machine’s settings.
The xm command provides a command line interface for
managing virtual machines. It can be used to create, pause, and shut down
virtual machines. It can also be used to list the current domains, enable
or pin virtual CPUs, and attach or detach block devices. For a complete
list of the available xm commands, run xm
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 xm.
For example, the xm list --help displays all options that are available to the list command. As an example, the xm list command displays the status of all virtual machines.
# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 457 2 r----- 2712.9 OES 7 512 1 -b---- 16.3 SLES10 512 1 12.9
The r
(running) and b (blocked) where blocked means it is either waiting for
IO, or just sleeping because there is nothing to do. For more details
about the state flags, see man 1 xm. The syntax of the
xm command usually follows the format:
xm <subcommand> [domain-id] [OPTIONS]
where subcommand is the xm 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.
Other useful xm commands include:
xm start starts a virtual machine
xm reboot reboots a virtual machine
xm destroy immediately terminates a virtual machine
xm block-list displays all virtual block devices attached to a virtual machine
All xm operations require that the Xen control daemon, Xend, be running. For this reason, you should make sure Xend starts whenever the host boots.
Most xm commands require root privileges to allow interaction with the Xen hypervisor. Entering the xm command when you are not logged in as root returns an error.
Some xm commands return no textual information even though the action is completed. In some instances, for example, when shutting down a virtual machine, the action can take several seconds to complete. To verify that the action has completed, you might need to view its status another way, such as, using the xm list command.
If you need automatic starting of domains at boot time, or after a crash, the Xend must be configured to execute the desired behavior. There are five different situations that need to be handled.
Set the Xend variable on_xend_start
to the desired
value. For more details, see the section called “on_xend_start”.
Example:
(on_xend_start start)
Xend can tell the VM Guest system to shut down. However, it does not to check if the guest was stopped when doing a system shutdown of Domain0. Thus, it is not recommended to rely on this feature. Example:
(on_xend_stop shutdown)
Xend has control about what to do when a VM Guest does a reboot. By default, it is restart the guest:
(on_reboot restart)
When a guest is shut off, the Xend by default destroys the guest without shutting it down.
(on_poweroff destroy)
After a VM Guest crashes, the Xend can restart the guest. This is also the default:
(on_crash restart)
With Xen it is possible to migrate a VM Guest system from one VM Host Server to another with almost no service interruption. This could be used for example to move a busy VM Guest to a VM Host Server that has stronger hardware or is not yet loaded. Or, if a service of a VM Host Server is required, all VM Guest systems running on this machine can be migrated to other machines in order to avoid interruption of service. These are only two examples, many more reasons may apply to your personal situation.
Before starting, some preliminary considerations regarding the VM Host Server should be taken:
All VM Host Server systems should use a similar CPU. The frequency is not so important, but they should be using the same CPU family. To get more information about the used CPU, see cat /proc/cpuinfo.
All resources that are used by a specific guest system must be available on all involved VM Host Server systems. This means, the network bridges must be in the same subnet, and all used block devices must exist on both VM Host Server systems.
Using special features like PCI Pass-Through
may be
problematic. Do not implement these when deploying for an environment
that should migrate VM Guest systems between different VM Host Server
systems.
For fast migrations, a fast network is mandatory. If possible, use GB Ethernet and fast Switches. Deploying VLAN might also help avoiding collisions.
To prepare a VM Host Server system for migrating, edit the configuration file
/etc/xen/xend-config.sxp
. Search for the following
lines:
#(xend-relocation-server no) #(xend-relocation-port 8002) (xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
Change the lines to match the following strings:
(xend-relocation-server yes) (xend-relocation-port 8002) (xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$ \ ^<relocation_host>')
These changes must be done on all VM Host Server systems that should participate in migrating guests.
The block devices needed by the VM Guest system must be available on all involved VM Host Server systems. This is done by implementing some kind of shared storage that serves as container for the root file system of the migrated VM Guest system. Common possibilities include:
iSCSI
can be set up to give access to the same
block devices from different systems at the same time. For more
information about iSCSI, see
http://www.novell.com/documentation/sles11/stor_admin/data/cha_inst_system_iscsi.html.
NFS
is a widely used root file system that can
easily be accessed from different locations.
DRBD
can be used, if only two VM Host Server systems are
involved. This gives some extra data security, because the used data
is mirrored over the network. For more information, see
http://www.novell.com/documentation/sles11/book_sleha/data/cha_ha_drbd.html.
SCSI
can also be used, if the available hardware
permits shared access to the same disks.
NPIV
is a special mode to use fibre channel disks.
However, in this case all migration hosts must be attached to the same
fibre channel switch. For more information about NPIV, see
Section 7.1, “Mapping Physical Storage to Virtual Disks”. Commonly, this works if
the fibre channel environment supports 4 GBit or faster connections.
The actual migration of the VM Guest system is done with the command:
xm migrate --live <domain_name> <host>
The option --live
must be set to migrate a
system that is currently running.
The speed of the migration depends on how fast the memory print can be saved to disk, sent to the new VM Host Server and loaded there. This means, that small VM Guest systems can be migrated faster than big systems with a lot of memory.