Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Server 11 SP4

5 Managing a Virtualization Environment

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.

Desktop Showing Virtual Machine Manager and Virtual Machines
Figure 5.1: Desktop Showing Virtual Machine Manager and Virtual Machines

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.

5.1 Virtual Machine Manager

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.

Note
Note

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.

Virtual Machine Manager Main Console
Figure 5.2: Virtual Machine Manager Main Console

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:

  1. Make sure that Domain0 on the VM Host Server accepts incoming SSH connections. If in doubt, run YaST › Security and Users › Firewall and make sure that Secure Shell Server is added to the Allowed Services.

  2. Run File › Add Connection.

  3. Select Xen at the Hypervisor pull-down menu.

  4. Check Connect to remote host

  5. Select SSH at the Method pull down menu.

  6. Enter the username for the SSH connection into the Username text field.

  7. Enter the hostname of the controlling Domain0 into the Hostname text field.

  8. Press Connect to initiate the connection.

  9. On request, enter the password of the 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.

  • Select a virtual machine and click Open to display the virtual machine window showing the virtual machine’s current state.

  • Click Run 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 Details to let you view performance and configure hardware details associated with the virtual machine.

  • Click New in Virtual Machine Manager to launch the Create Virtual Machine Wizard, which walks you through the steps required to set up a virtual machine. See also Section 3.1, “Creating a Virtual Machine”. This option is only available when the Xen host is selected.

5.2 Controlling the Host by Modifying Xend Settings

The 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
    # uses 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.

5.3 Configuring a Virtual Machine by Modifying its Xend Settings

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.

Note
Note

It is no longer recommended that you edit the initial start-up files stored in /etc/xen/vm, because they are used only during the creation of a new virtual machine.

To modify a virtual machine’s settings that is administrated with the virtual machine manager, first shut it down and then:

  1. 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.

  2. 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)                                  
    ....
  3. Delete the existing configuration from Xend with the command xm del vm_name

  4. Enter xm new -F filename to import the virtual machine’s new settings into Xend.

  5. 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.

5.4 The xm Command

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 State information tells if a machine is running, and in which state it is. The most common flags are 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.

5.5 Automatic Starting of Domains

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.

After boot of the Hypervisor

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)
When shutting down Xend

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)
When rebooting the VM Guest

Xend has control about what to do when a VM Guest does a reboot. By default, it is restart the guest:

(on_reboot restart)
During poweroff of a VM Guest

When a guest is shut off, the Xend by default destroys the guest without shutting it down.

(on_poweroff destroy)
After a crash of the VM Guest

After a VM Guest crashes, the Xend can restart the guest. This is also the default:

(on_crash restart)

5.6 Migrating Xen VM Guest Systems

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.

5.6.1 Configuring Xend for Migrations

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.

5.6.2 Preparing Block Devices for Migrations

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:

5.6.3 Migrating VM Guest Systems

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.

Print this page