11 Basic VM Guest management #
Most management tasks, such as starting or stopping a VM Guest, can either
be done using the graphical application Virtual Machine Manager or on the command line using
virsh. Connecting to the graphical console via VNC is
only possible from a graphical user interface.
If started on a VM Host Server, the libvirt tools Virtual Machine Manager,
virsh, and virt-viewer can be used
to manage VM Guests on the host. However, it is also possible to manage
VM Guests on a remote VM Host Server. This requires configuring remote access
for libvirt on the host. For instructions, see
Chapter 12, Connecting and authorizing.
To connect to such a remote host with Virtual Machine Manager, you need to set up a
connection as explained in
Section 12.2.2, “Managing connections with Virtual Machine Manager”. If connecting to a
remote host using virsh or
virt-viewer, you need to specify a connection URI with
the parameter -c, for example, virsh -c
qemu+tls://saturn.example.com/system or virsh -c
xen+ssh://. The form of connection URI depends on the
connection type and the hypervisor—see
Section 12.2, “Connecting to a VM Host Server” for details.
Examples in this chapter are all listed without a connection URI.
11.1 Listing VM Guests #
The VM Guest listing shows all VM Guests managed by libvirt on a
VM Host Server.
11.1.1 Listing VM Guests with Virtual Machine Manager #
The main window of the Virtual Machine Manager lists all VM Guests for each VM Host Server it is connected to. Each VM Guest entry contains the machine's name, its status (, , or ) displayed as an icon and literally, and a CPU usage bar.
11.1.2 Listing VM Guests with virsh #
Use the command virsh list to get a
list of VM Guests:
- List all running guests
>virsh list- List all running and inactive guests
>virsh list --all
For more information and further options, see virsh help
list or man 1 virsh.
11.2 Accessing the VM Guest via console #
VM Guests can be accessed via a VNC connection (graphical console) or, if supported by the guest operating system, via a serial console.
11.2.1 Opening a graphical console #
Opening a graphical console to a VM Guest lets you interact with the machine like a physical host via a VNC connection. If accessing the VNC server requires authentication, you are prompted to enter a user name (if applicable) and a password.
When you click into the VNC console, the cursor is “grabbed” and cannot be used outside the console anymore. To release it, press Alt–Ctrl.
To prevent the console from grabbing the cursor and to enable seamless cursor movement, add a tablet input device to the VM Guest. See Section 14.5, “Input devices” for more information.
Certain key combinations such as Ctrl–Alt–Del are interpreted by the host
system and are not passed to the VM Guest. To pass such key
combinations to a VM Guest, open the menu
from the VNC window and choose the desired key combination entry. The
menu is only available when using Virtual Machine Manager and
virt-viewer. With Virtual Machine Manager, you can alternatively use
the “sticky key” feature as explained in
Tip: Passing key combinations to virtual machines.
Principally all VNC viewers can connect to the console of a
VM Guest. However, if you are using SASL authentication and/or
TLS/SSL connection to access the guest, the options are limited.
Common VNC viewers such as tightvnc or
tigervnc support neither SASL authentication nor
TLS/SSL. The only supported alternative to Virtual Machine Manager and
virt-viewer is Remmina (refer to
14.2項 「Remmina: リモートデスクトップクライアント」).
11.2.1.1 Opening a graphical console with Virtual Machine Manager #
In the Virtual Machine Manager, right-click a VM Guest entry.
Choose from the pop-up menu.
11.2.1.2 Opening a graphical console with virt-viewer #
virt-viewer is a simple VNC viewer with added
functionality for displaying VM Guest consoles. For example, it can
be started in “wait” mode, where it waits for a
VM Guest to start before it connects. It also supports automatically
reconnecting to a VM Guest that is rebooted.
virt-viewer addresses VM Guests by name, by ID or
by UUID. Use virsh list --all to
get this data.
To connect to a guest that is running or paused, use either the ID, UUID or name. VM Guests that are shut off do not have an ID—you can only connect to them by UUID or name.
- Connect to guest with the ID
8 >virt-viewer 8- Connect to the inactive guest named
sles12; the connection window opens once the guest starts >virt-viewer --wait sles12With the
--waitoption, the connection is upheld even if the VM Guest is not running at the moment. When the guest starts, the viewer is launched.
For more information, see virt-viewer
--help or man 1 virt-viewer.
When using virt-viewer to open a connection to a
remote host via SSH, the SSH password needs to be entered twice.
The first time for authenticating with libvirt, the second time
for authenticating with the VNC server. The second password needs
to be provided on the command line where virt-viewer was started.
11.2.2 Opening a serial console #
Accessing the graphical console of a virtual machine requires a
graphical environment on the client accessing the VM Guest. As an
alternative, virtual machines managed with libvirt can also be accessed
from the shell via the serial console and virsh. To
open a serial console to a VM Guest named “sles12”, run
the following command:
> virsh console sles12
virsh console takes two optional flags:
--safe ensures exclusive access to the console,
--force disconnects any existing sessions before
connecting. Both features need to be supported by the guest operating
system.
Being able to connect to a VM Guest via serial console requires that the guest operating system supports serial console access and is properly supported. Refer to the guest operating system manual for more information.
Serial console access in SUSE Linux Enterprise and openSUSE is disabled by default. To enable it, proceed as follows:
- SLES 12, 15 and openSUSE
Launch the YaST Boot Loader module and switch to the tab. Add
console=ttyS0to the field .- SLES 11
Launch the YaST Boot Loader module and select the boot entry for which to activate serial console access. Choose and add
console=ttyS0to the field . Additionally, edit/etc/inittaband uncomment the line with the following content:#S0:12345:respawn:/sbin/agetty -L 9600 ttyS0 vt102
11.3 Changing a VM Guest's state: start, stop, pause #
Starting, stopping or pausing a VM Guest can be done with either Virtual Machine Manager
or virsh. You can also configure a VM Guest to be
automatically started when booting the VM Host Server.
When shutting down a VM Guest, you may either shut it down gracefully, or force the shutdown. The latter is equivalent to pulling the power plug on a physical host and is only recommended if there are no alternatives. Forcing a shutdown may cause file system corruption and loss of data on the VM Guest.
To be able to perform a graceful shutdown, the VM Guest must be configured to support ACPI. If you have created the guest with the Virtual Machine Manager, ACPI should be available in the VM Guest.
Depending on the guest operating system, availability of ACPI may not be sufficient to perform a graceful shutdown. It is strongly recommended to test shutting down and rebooting a guest before using it in production. openSUSE or SUSE Linux Enterprise Desktop, for example, can require Polkit authorization for shutdown and reboot. Make sure this policy is turned off on all VM Guests.
If ACPI was enabled during a Windows XP/Windows Server 2003 guest installation, turning it on in the VM Guest configuration only is not sufficient. For more information, see:
Regardless of the VM Guest's configuration, a graceful shutdown is always possible from within the guest operating system.
11.3.1 Changing a VM Guest's state with Virtual Machine Manager #
Changing a VM Guest's state can be done either from Virtual Machine Manager's main window, or from a VNC window.
Right-click a VM Guest entry.
Choose , , or one of the from the pop-up menu.
Open a VNC Window as described in Section 11.2.1.1, “Opening a graphical console with Virtual Machine Manager”.
Choose , , or one of the options either from the toolbar or from the menu.
11.3.1.1 Automatically starting a VM Guest #
You can automatically start a guest when the VM Host Server boots. This feature is not enabled by default and needs to be enabled for each VM Guest individually. There is no way to activate it globally.
Double-click the VM Guest entry in Virtual Machine Manager to open its console.
Choose › to open the VM Guest configuration window.
Choose and check .
Save the new configuration with .
11.3.2 Changing a VM Guest's state with virsh #
In the following examples, the state of a VM Guest named “sles12” is changed.
- Start
>virsh start sles12- Pause
>virsh suspend sles12- Resume (a suspended VM Guest)
>virsh resume sles12- Reboot
>virsh reboot sles12- Graceful shutdown
>virsh shutdown sles12- Force shutdown
>virsh destroy sles12- Turn on automatic start
>virsh autostart sles12- Turn off automatic start
>virsh autostart --disable sles12
11.4 Saving and restoring the state of a VM Guest #
Saving a VM Guest preserves the exact state of the guest’s memory. The operation is similar to hibernating a computer. A saved VM Guest can be quickly restored to its previously saved running condition.
When saved, the VM Guest is paused, its current memory state is saved to disk, and then the guest is stopped. The operation does not make a copy of any portion of the VM Guest’s virtual disk. The amount of time taken to save the virtual machine depends on the amount of memory allocated. When saved, a VM Guest’s memory is returned to the pool of memory available on the VM Host Server.
The restore operation loads a VM Guest’s previously saved memory state file and starts it. The guest is not booted but instead resumed at the point where it was previously saved. The operation is similar to coming out of hibernation.
The VM Guest is saved to a state file. Make sure there is enough space on the partition you are going to save to. For an estimation of the file size in megabytes to be expected, issue the following command on the guest:
> free -mh | awk '/^Mem:/ {print $3}'
After using the save operation, do not boot or start the saved VM Guest. Doing so would cause the machine's virtual disk and the saved memory state to get out of synchronization. This can result in critical errors when restoring the guest.
To be able to work with a saved VM Guest again, use the restore
operation. If you used virsh to save a VM Guest,
you cannot restore it using Virtual Machine Manager. In this case, make sure to restore
using virsh.
If you restore the VM Guest after a long pause (hours) since it was
saved, its time synchronization service, for example,
chronyd, may refuse to synchronize its time. In this case,
manually synchronize VM Guest's time. For example, for KVM hosts,
you can use the QEMU guest agent and instruct the guest with the
guest-set-time. Refer to
Chapter 22, QEMU guest agent for more details.
raw, qcow2
Saving and restoring VM Guests is only possible if the VM Guest is
using a virtual disk of the type raw
(.img), or qcow2.
11.4.1 Saving/restoring with Virtual Machine Manager #
Open a VNC connection window to a VM Guest. Make sure the guest is running.
Choose › › .
Open a VNC connection window to a VM Guest. Make sure the guest is not running.
Choose › .
If the VM Guest was previously saved using Virtual Machine Manager, you are not offered an option to the guest. However, note the caveats on machines saved with
virshoutlined in Warning: Always restore saved guests.
11.4.2 Saving and restoring with virsh #
Save a running VM Guest with the command virsh
save and specify the file which it is saved to.
- Save the guest named
opensuse13 >virsh save opensuse13 /virtual/saves/opensuse13.vmsav- Save the guest with the ID
37 >virsh save 37 /virtual/saves/opensuse13.vmsave
To restore a VM Guest, use virsh
restore:
> virsh restore /virtual/saves/opensuse13.vmsave11.5 Creating and managing snapshots #
VM Guest snapshots are snapshots of the complete virtual machine including the state of CPU, RAM, devices and the content of all writable disks. To use virtual machine snapshots, all the attached hard disks need to use the qcow2 disk image format, and at least one of them needs to be writable.
Snapshots let you restore the state of the machine at a particular point in time. This is useful when undoing a faulty configuration or the installation of a lot of packages. After starting a snapshot that was created while the VM Guest was shut off, you need to boot it. Any changes written to the disk afterward are lost when starting the snapshot.
Snapshots are supported on KVM VM Host Servers only.
11.5.1 Terminology #
There are several specific terms used to describe the types of snapshots:
- Internal snapshots
Snapshots that are saved into the qcow2 file of the original VM Guest. The file holds both the saved state of the snapshot and the changes made since the snapshot was taken. The main advantage of internal snapshots is that they are all stored in one file and therefore it is easy to copy or move them across multiple machines.
- External snapshots
When creating an external snapshot, the original qcow2 file is saved and made read-only, while a new qcow2 file is created to hold the changes. The original file is sometimes called a backing or base file, while the new file with all the changes is called an overlay or derived file. External snapshots are useful when performing backups of VM Guests. However, external snapshots are not supported by Virtual Machine Manager, and cannot be deleted by
virshdirectly. For more information on external snapshots in QEMU, refer to Section 36.2.4, “Manipulate disk images effectively”.- Live snapshots
Snapshots created when the original VM Guest is running. Internal live snapshots support saving the devices, and memory and disk states, while external live snapshots with
virshsupport saving either the memory state, or the disk state, or both.- Offline snapshots
Snapshots created from a VM Guest that is shut off. This ensures data integrity as all the guest's processes are stopped and no memory is in use.
11.5.2 Creating and managing snapshots with Virtual Machine Manager #
Virtual Machine Manager supports only internal snapshots, either live or offline.
To open the snapshot management view in Virtual Machine Manager, open the VNC window as described in Section 11.2.1.1, “Opening a graphical console with Virtual Machine Manager”. Now either choose › or click in the toolbar.
The list of existing snapshots for the chosen VM Guest is displayed in the left-hand part of the window. The snapshot that was last started is marked with a green tick. The right-hand part of the window shows details of the snapshot currently marked in the list. These details include the snapshot's title and time stamp, the state of the VM Guest at the time the snapshot was taken and a description. Snapshots of running guests also include a screenshot. The can be changed directly from this view. Other snapshot data cannot be changed.
11.5.2.1 Creating a snapshot #
To take a new snapshot of a VM Guest, proceed as follows:
Optionally, shut down the VM Guest to create an offline snapshot.
Click in the bottom left corner of the VNC window.
The window opens.
Provide a and, optionally, a description. The name cannot be changed after the snapshot has been taken. To be able to identify the snapshot later easily, use a “speaking name”.
Confirm with .
11.5.2.2 Deleting a snapshot #
To delete a snapshot of a VM Guest, proceed as follows:
Click in the bottom left corner of the VNC window.
Confirm the deletion with .
11.5.2.3 Starting a snapshot #
To start a snapshot, proceed as follows:
Click in the bottom left corner of the VNC window.
Confirm the start with .
11.5.3 Creating and managing snapshots with virsh #
To list all existing snapshots for a domain
(admin_server in the following), run the
snapshot-list command:
> virsh snapshot-list --domain sle-ha-node1
Name Creation Time State
------------------------------------------------------------
sleha_12_sp2_b2_two_node_cluster 2016-06-06 15:04:31 +0200 shutoff
sleha_12_sp2_b3_two_node_cluster 2016-07-04 14:01:41 +0200 shutoff
sleha_12_sp2_b4_two_node_cluster 2016-07-14 10:44:51 +0200 shutoff
sleha_12_sp2_rc3_two_node_cluster 2016-10-10 09:40:12 +0200 shutoff
sleha_12_sp2_gmc_two_node_cluster 2016-10-24 17:00:14 +0200 shutoff
sleha_12_sp3_gm_two_node_cluster 2017-08-02 12:19:37 +0200 shutoff
sleha_12_sp3_rc1_two_node_cluster 2017-06-13 13:34:19 +0200 shutoff
sleha_12_sp3_rc2_two_node_cluster 2017-06-30 11:51:24 +0200 shutoff
sleha_15_b6_two_node_cluster 2018-02-07 15:08:09 +0100 shutoff
sleha_15_rc1_one-node 2018-03-09 16:32:38 +0100 shutoff
The snapshot that was last started is shown with the
snapshot-current command:
> virsh snapshot-current --domain admin_server
Basic installation incl. SMT for CLOUD4
Details about a particular snapshot can be obtained by running the
snapshot-info command:
> virsh snapshot-info --domain admin_server \
-name "Basic installation incl. SMT for CLOUD4"
Name: Basic installation incl. SMT for CLOUD4
Domain: admin_server
Current: yes
State: shutoff
Location: internal
Parent: Basic installation incl. SMT for CLOUD3-HA
Children: 0
Descendants: 0
Metadata: yes11.5.3.1 Creating internal snapshots #
To take an internal snapshot of a VM Guest, either a live or
offline, use the snapshot-create-as command as
follows:
> virsh snapshot-create-as --domain admin_server1 --name "Snapshot 1"2 \
--description "First snapshot"311.5.3.2 Creating external snapshots #
With virsh, you can take external snapshots of the
guest's memory state, disk state, or both.
To take both live and offline external snapshots of the guest's disk,
specify the --disk-only option:
> virsh snapshot-create-as --domain admin_server --name \
"Offline external snapshot" --disk-only
You can specify the --diskspec option to control how
the external files are created:
> virsh snapshot-create-as --domain admin_server --name \
"Offline external snapshot" \
--disk-only --diskspec vda,snapshot=external,file=/path/to/snapshot_file
To take a live external snapshot of the guest's memory, specify the
--live and --memspec options:
> virsh snapshot-create-as --domain admin_server --name \
"Offline external snapshot" --live \
--memspec snapshot=external,file=/path/to/snapshot_file
To take a live external snapshot of both the guest's disk and memory
states, combine the --live,
--diskspec, and --memspec options:
> virsh snapshot-create-as --domain admin_server --name \
"Offline external snapshot" --live \
--memspec snapshot=external,file=/path/to/snapshot_file
--diskspec vda,snapshot=external,file=/path/to/snapshot_file
Refer to the SNAPSHOT COMMANDS section in
man 1 virsh for more details.
11.5.3.3 Deleting a snapshot #
External snapshots cannot be deleted with virsh.
To delete an internal snapshot of a VM Guest and restore the disk
space it occupies, use the snapshot-delete
command:
> virsh snapshot-delete --domain admin_server --snapshotname "Snapshot 2"11.5.3.4 Starting a snapshot #
To start a snapshot, use the snapshot-revert
command:
> virsh snapshot-revert --domain admin_server --snapshotname "Snapshot 1"
To start the current snapshot (the one the VM Guest was started
off), it is sufficient to use --current rather than
specifying the snapshot name:
> virsh snapshot-revert --domain admin_server --current11.6 Deleting a VM Guest #
By default, deleting a VM Guest using virsh removes
only its XML configuration. Since attached storage is not deleted by
default, you can reuse it with another VM Guest. With Virtual Machine Manager, you can
also delete a guest's storage files as well.
11.6.1 Deleting a VM Guest with Virtual Machine Manager #
In the Virtual Machine Manager, right-click a VM Guest entry.
From the context menu, choose .
A confirmation window opens. Clicking permanently erases the VM Guest. The deletion is not recoverable.
You can also permanently delete the guest's virtual disk by activating . The deletion is not recoverable either.
11.6.2 Deleting a VM Guest with virsh #
To delete a VM Guest, it needs to be shut down first. It is not possible to delete a running guest. For information on shutting down, see Section 11.3, “Changing a VM Guest's state: start, stop, pause”.
To delete a VM Guest with virsh, run
virsh undefine
VM_NAME.
> virsh undefine sles12There is no option to automatically delete the attached storage files. If they are managed by libvirt, delete them as described in Section 9.2.1.4, “Deleting volumes from a storage pool”.
11.7 Monitoring #
11.7.1 Monitoring with Virtual Machine Manager #
After starting Virtual Machine Manager and connecting to the VM Host Server, a CPU usage graph of all the running guests is displayed.
It is also possible to get information about disk and network usage with this tool, however, you must first activate this in :
Run
virt-manager.Select › .
Change the tab from to .
Activate the check boxes for the kind of activity you want to see: , , and .
If desired, also change the update interval using .
Close the dialog.
Activate the graphs that should be displayed under › .
Afterward, the disk and network statistics are also displayed in the main window of the Virtual Machine Manager.
More precise data is available from the VNC window. Open a VNC window as described in Section 11.2.1, “Opening a graphical console”. Choose from the toolbar or the menu. The statistics are displayed from the entry of the left-hand tree menu.
11.7.2 Monitoring with virt-top #
virt-top is a command-line tool similar to the
well-known process monitoring tool top.
virt-top uses libvirt and therefore is capable of
showing statistics for VM Guests running on different hypervisors. It
is recommended to use virt-top instead of
hypervisor-specific tools like xentop.
By default virt-top shows statistics for all running
VM Guests. Among the data that is displayed is the percentage of
memory used (%MEM) and CPU (%CPU)
and the uptime of the guest (TIME). The data is
updated regularly (every three seconds by default). The following shows
the output on a VM Host Server with seven VM Guests, four of them inactive:
virt-top 13:40:19 - x86_64 8/8CPU 1283MHz 16067MB 7.6% 0.5%
7 domains, 3 active, 3 running, 0 sleeping, 0 paused, 4 inactive D:0 O:0 X:0
CPU: 6.1% Mem: 3072 MB (3072 MB by guests)
ID S RDRQ WRRQ RXBY TXBY %CPU %MEM TIME NAME
7 R 123 1 18K 196 5.8 6.0 0:24.35 sled12_sp1
6 R 1 0 18K 0 0.2 6.0 0:42.51 sles12_sp1
5 R 0 0 18K 0 0.1 6.0 85:45.67 opensuse_leap
- (Ubuntu_1410)
- (debian_780)
- (fedora_21)
- (sles11sp3)By default the output is sorted by ID. Use the following key combinations to change the sort field:
| Shift–P: CPU usage |
| Shift–M: Total memory allocated by the guest |
| Shift–T: time |
| Shift–I: ID |
To use any other field for sorting, press Shift–F and select a field from the list. To toggle the sort order, use Shift–R.
virt-top also supports different views on the
VM Guests data, which can be changed on-the-fly by pressing the
following keys:
| 0: default view |
| 1: show physical CPUs |
| 2: show network interfaces |
| 3: show virtual disks |
virt-top supports more hot keys to change the view
of the data and many command line switches that affect the behavior of
the program. For more information, see man 1
virt-top.
11.7.3 Monitoring with kvm_stat #
kvm_stat can be used to trace KVM performance
events. It monitors /sys/kernel/debug/kvm, so it
needs the debugfs to be mounted. On SUSE Linux Enterprise Server it should be mounted
by default. In case it is not mounted, use the following command:
>sudomount -t debugfs none /sys/kernel/debug
kvm_stat can be used in three different modes:
kvm_stat # update in 1 second intervals
kvm_stat -1 # 1 second snapshot
kvm_stat -l > kvmstats.log # update in 1 second intervals in log format
# can be imported to a spreadsheetkvm_stat #kvm statistics efer_reload 0 0 exits 11378946 218130 fpu_reload 62144 152 halt_exits 414866 100 halt_wakeup 260358 50 host_state_reload 539650 249 hypercalls 0 0 insn_emulation 6227331 173067 insn_emulation_fail 0 0 invlpg 227281 47 io_exits 113148 18 irq_exits 168474 127 irq_injections 482804 123 irq_window 51270 18 largepages 0 0 mmio_exits 6925 0 mmu_cache_miss 71820 19 mmu_flooded 35420 9 mmu_pde_zapped 64763 20 mmu_pte_updated 0 0 mmu_pte_write 213782 29 mmu_recycled 0 0 mmu_shadow_zapped 128690 17 mmu_unsync 46 -1 nmi_injections 0 0 nmi_window 0 0 pf_fixed 1553821 857 pf_guest 1018832 562 remote_tlb_flush 174007 37 request_irq 0 0 signal_exits 0 0 tlb_flush 394182 148
See https://clalance.blogspot.com/2009/01/kvm-performance-tools.html for further information on how to interpret these values.