KVM Guest Snapshots with Libvirt

VMs have a lot of use cases, one of which is the capacity of VMs to be used as test machines. You can experiment within a VM, apply patches and test upgrades before the doing the same on your production systems or your workstation. You can also use disposable VMs, that lacks personal or sensitive data, for malware testing as most of the security community does, just make sure that the VM’s network is isolated from your host and LAN.

However, it does get tiresome to reinstall the operating system inside your VM over and over again. It hinders your workflow and, therefore, you need a reliable way to:

  1. Take a snapshot of your VM at any given point in time.
  2. Have a mechanism to use the snapshot to revert your VM back to a previously working state.

I have previously discussed how snapshots work in VirtualBox and this time I wanted to discuss snapshots within Libvirt. I will be using QEMU-KVM as the backend hypervisor for my Libvirt installation. Your case might differ, but the overall functionality and interface should not be very different, since libvirt tries its best to standardize the frontend interface.

If you are not familiar with libvirt and qemu-kvm, here’s a guide on how you can setup KVM on Debian.

Creating a Snapshot

There are several ways with which you can take and manage snapshots of your VM. GUI applications like virt-manager and oVirt offers the functionality and you can even write custom scripts to interface with libvirt API that manages the entire range of snapshots for you.

However, I will be using virsh command line interface to show how you can manage your VMs and their snapshots. This utility comes with almost all default libvirt installations and should be available across a wide range of distributions.

For the commands below make sure to replace the name of my VM, VM1, with the actual name of your VM. Libvirt often refers to virtual machine and containers as Domains. So if you see an error message suggesting,say, “specify domain name”, you need to supply your VM’s name as one of the arguments to the command. Use the following command to list all the VMs under Libvirt’s management.

$ virsh list --all

To take a snapshot of a VM simply run:

$ virsh snapshot-create VM1

And to list all the snapshots of a given VM use the command:

$ virsh snapshot-list VM1
Name                 Creation Time             State

1556533387           2019-04-29 15:53:07 +0530 running

You can see that the snapshot is created. By default, the name of the snapshot is its creation time stamp (the number of seconds since UNIX epoch). The Creation Time column shows the time of creation in a human readable fashion and the State column shows the state of the VM when it was snapshotted. The as this VM was running, the snapshot’s state is also ‘running’, but that doesn’t meant that the snapshot itself is running. It won’t change with time. This feature is also known as live snapshot and it is quite valuable since it allows you to take a snapshot of your VM without any downtime. The KVM guests, at least, work fine with live snapshots.

Certain workloads, however, do require you to stop of the VM before it is snapshotted. This ensures that the data in the snapshot is consistent and there’s no half-written file or missing data. If the workload running in your VM has high IO, you probably need to turn the VM off before creating the snapshot. Let’s create one this way.

$ virsh shutdown VM1

Domain VM1 is being shutdown

$ virsh snapshot-create VM1

Domain snapshot 1556533868 created

root@deb:~# virsh snapshot-list VM1
Name                 Creation Time             State
1556533387           2019-04-29 15:53:07 +0530 running
1556533868           2019-04-29 16:01:08 +0530 shutoff
$ virsh start VM1
Domain VM1 started

If you want to name the snapshots something other than timestamp, use the command:

$ virsh snapshot-create-as VM1 --name snap1
Name                 Creation Time             State
1556533387           2019-04-29 15:53:07 +0530 running
1556533868           2019-04-29 16:01:08 +0530 shutoff
snap1                2019-05-02 22:27:48 +0530 running

Obviously, you don’t have to name it snap1, you can pick any convenient name.

Reverting back from a Snapshot

To take a snapshot is of no use if you can’t go back to it. In case, you need to revert back to a snapshot simply use the command:

$ virsh snapshot-revert $VMName $snapshot-name

The name can be the timestamp or the user assigned name given to the snapshot.

Make sure that there’s no important data in your current VM, or if there is anything of importance, then take snapshot of your current VM and then revert back to an older snapshot.

Benefits of QCOW2

The copy-on-write mechanism of qcow2 files allows each snapshot to take very small space. The space taken by a snapshot increases over time as the running image diverges from the snapshot. So as long as you are not rewriting a lot of data, your snapshots will take only a few MBs of storage.

It also means that the snapshots are very fast  as well. Since, the copy-on-write mechanism just needs to mark the timestamp when the snapshot was taken. The data blocks written to the qcow2 file after the snapshot don’t belong to it, but the older ones do. It is as simple as that. My test bench uses a 5400RPM hard drive that is by no means at the peak of its performance, it still takes less than a few seconds to take a live snapshot of a VM on this disk.


As with most libvirt and virsh related utilities, the snapshot functionality provides a very flexible interface with enterprise grade features like live snapshotting along with the benefits of copy-on-write mechanism.

The default naming convention also makes it easier for shell scripts to periodically remove old snapshots and replace them with newer ones. One of my older articles on OpenZFS snapshots and snapshot policies can also be applied for your KVM guest. For more information about the virsh snapshot utility you can use virsh help snapshot command. The help page is very small, precise and easy to understand.

About the author

Ranvir Singh

I am a tech and science writer with quite a diverse range of interests. A strong believer of the Unix philosophy. Few of the things I am passionate about include system administration, computer hardware and physics.