Snapshots

Virtual machine snapshots are practically an indispensable part of the system administrator's everyday life. A snapshot freezes the state of a virtual machine and writes it to disk. Snapshots are useful for a variety of tasks, depending on the application and the type. For example, snapshots let you repeatedly restore the original state of a virtual machine without having to create multiple VMs. A recovery point generated via a snapshot thus retains the initial state, before a developer or admin makes further changes to the VM. This explains why developers really like using snapshots.

Snapshots are also a useful tool for patching applications or servers. Thus, administrators like to use snapshots when they suspect a configuration error or see signs of the imminent demise of a hardware component. If you suspect a break-in or need to secure proof in forensic investigations, a VM snapshot can be a useful tool. Admins also can, for example, use VM checkpointing to create as many snapshots of their VM  – including multiple restore points  – as needed.

Internal and External Snapshots

The different types of snapshots also differ in terms of whether the RAM state and the filesystem of the VM are frozen. All well-known virtualization solutions today support snapshots. In this article, I cover the kind of snapshots provided by the Linux libvirt abstraction layer, especially those that can be used in the graphical front end, Virtual Machine Manager (VMM) [1].

In general, Qemu [2] or libvirt [3] distinguish between internal and external snapshots. For internal snapshots, libvirt freezes the complete state of the current virtual machine and writes the snapshot directly to the image file of the virtual disk. This includes the RAM content state for the virtual machine, as well as the virtual device and virtual disk states.

Only the XML files needed for a management interface to access the recovery points are stored under /var/lib/libvirt/qemu/snapshot/VM for a VMM connected to the local hypervisor in the typical way. However, internal snapshots only work if you use the qcow2 format, which supports copy-on-write, when defining the virtual machine for the virtual disk. To change the image format, you need to switch the VMM to the detailed view at the console and then unfold the Advanced options for the disk device highlighted on the left (Figure 1).

Internal snapshots, however, cannot easily be backed up – after all, they are part of the image, and the virtual machine is typically still running normally. You could suspend the virtual machine for a short while to back up the entire image.

Alternatively, Libvirt supports external snapshots, in which the RAM content ends up in a file to be specified, and the original disk image is frozen, with any changes then written to a new image. However, to create external snapshots (live checkpointing), you will need to use Virsh [4].

The reason for talking about snapshots now is that the graphical VMM that ships with Fedora 20 also supports internal snapshots. You might suppose that VMM could already handle snapshots, because even the older versions had a Save option in the drop-down menu for stopping a virtual machine, but you would be wrong – or at least a bit wrong.

What this feature actually does is freeze the state of the virtual machine and write the contents of the VM's RAM to the disk image. However, the function completely stops the virtual machine after freezing to disk; it is thus no more than a power-saving suspend-to-disk method that lets the VMM immediately return to the last known state the next time it boots. In this case, however, the operating system in the VM has no knowledge of the process, because it is entirely controlled by libvirt – after being initiated by the VMM.

The disadvantage compared with the support for internal snapshots recently implemented in VMM is that the virtual machine is shut down after freezing. This disqualifies the method, for example, as a safety net for developers or for admins trying to home in on a configuration or hardware problem. Incidentally, the function always creates only one backup and removes it again the next time the VM starts. As with a normal suspend-to-disk function on physical hardware, it is useful to speed up the next boot.

Internal Snapshots with VMM

Cole Robinson's entry in the Fedora wiki [5] covers a whole range of snapshot parameters associated with virsh, including live backups. For example, if a virtual machine named RHEL6 is running under libvirt, you can type:

virsh snapshot-create-as myvm snapshot1 "My Snapshot" --disk-only --atomic

to force a simple live backup with the parameter --disk-only.

However, in the version implemented with Fedora, VMM can now handle live snapshots. You can create a snapshot manually as follows:

virsh -c qemu:////system snapshot-create-as rhel6 "snap1" "This is a snapshot of rhel6"

The command is acknowledged with a domain snapshot snap1 created message. The virtual machine continues to run. If you now launch a recent developer version of the VMM, the snapshot should appear under View | Snapshots (Figure 2).

This feature not always been available. The current regular VMM 0.10.0 version from June 2013 may be available from the repositories of the major distributions, but it does not yet support the new feature or, for that matter, the ability to create internal snapshots in the GUI. Enabling the developer virtualization packages in the form of the Virtualization packages from Rawhide built for latest Fedora - Source lets you install the required VMM 0.10.5 version on Fedora 19. Optionally, you can check out a current version of VMM from Git at any time.

It works on Fedora 19, but only if you update Qemu from version 1.4.2 to version 1.6.1 from the same source package at the same time. Despite doing so, the newly installed 0.10.5 version comes up with an error message of virt-manager cannot start guest because cannot load libGL.so.1 the first time you attempt to start a guest system. This problem was relatively quickly identified as a known bug [6] and currently can only be eliminated on Fedora, CentOS, and RHEL by disabling SELinux.

After entering setenforce 0, you can then grab internal snapshots in the GUI tool on Fedora 19, too. To this end, you can change from the console view to the current snapshot list by selecting View | Snapshots. A click on the plus icon at the bottom left of the dialog box then generates a new snapshot. All you need to do here is enter a name and a description for the snapshot.

You can change the description (but only the description, mind you!) in retrospect. VMM displays a progress bar to show you when freezing the virtual machine is complete. VMM then adds the finished snapshot and a screenshot to the list.

When you click an existing snapshot in the list on the left, you can see the details on the right; they include the name of the snapshot, the creation date (Timestamp) and whether the virtual machine continued to run after the snapshot was taken (VM State). If this is the case, which is the default in VMM, and a screenshot was generated when creating the snapshot, you will also see the screenshot.

However, because you can also produce internal snapshots manually, you might see some cases in which the virtual machine was stopped. To restore an existing snapshot, press the Play icon at the bottom left next to the plus button. VMM restores the state immediately after you confirm the safety prompt (Figure 3).

GUI Tools with Snapshot

Linux has a number of other libvirt-based virtualization management interfaces that support snapshots. Red Hat Enterprise Virtualization (RHEV) and its free counterpart oVirt have supported live snapshots since version 3.1, typically implemented as COWs (Copy-On-Writes). The Proxmox VE virtualization management solution, which is also built on libvirt, has supported live snapshots since version 2.3 [7], provided that qcow2 is used as the image format of the virtual disks.

Conclusions

Virtual Machine Manager is a useful helper for many system administrators; in particular, it is an obvious choice for managing remote hypervisors. However, the development rate is relatively conservative compared with libvirt so the current official version (0.10.0) is far removed from mapping all the options that libvirt currently offers in the GUI. Fedora 20 comes with development version 0.10.5 out of the box, thus letting admins create internal snapshots in the GUI.