KVM snapshots and cloning with virsh and virt-clone

Snapshots save a VM’s state so you can go back after a failed change. Clones copy a VM to make a new one. Both are built into libvirt tooling, but both have sharp edges worth understanding before you rely on them.

Snapshot types

libvirt’s snapshot documentation distinguishes:

• Disk snapshot: disk contents at a point in time.
• Full system snapshot: disk snapshots of all disks plus the VM’s memory state, so a running VM resumes exactly where it was.
• Internal: the snapshot and later changes are kept in a single file, for example inside a qcow2 image.
• External: the snapshot is one file and changes after it go into another (an overlay).

Which kind you get depends on your disks, options and libvirt version. After creating a snapshot, check with virsh snapshot-list VM --internal or --external, or read virsh snapshot-dumpxml.

Create and list snapshots

virsh snapshot-create-as web01 --name pre-update --description "before kernel update" --atomic
virsh snapshot-list web01
virsh snapshot-list web01 --tree
virsh snapshot-current web01 --name

--atomic asks libvirt to either succeed fully or change nothing, where the hypervisor supports it. A disk-only snapshot of a running VM is more consistent if the QEMU guest agent can freeze file systems first; --quiesce does that and requires --disk-only, and fails if no guest agent is running:

virsh snapshot-create-as web01 --name pre-deploy --disk-only --quiesce --atomic

Revert to a snapshot

Warning: reverting is destructive. Everything that changed in the VM since the snapshot is lost. If you might need current data, copy it out of the VM or take a new snapshot first, and confirm the snapshot name with snapshot-list.

virsh snapshot-list web01
virsh snapshot-revert web01 pre-update
virsh snapshot-revert web01 pre-update --running

After a revert the VM is in the state it had when the snapshot was taken. A disk-only snapshot has no memory state, so the VM is left shut off; --running boots it afterwards.

Delete snapshots

Deleting a snapshot removes that restore point; if it has children, its changes are merged into them. Snapshots are not backups: they live on the same storage as the VM and lose their value if that storage fails. Delete them when the change has been verified, because long snapshot chains cost disk space and I/O.

virsh snapshot-delete web01 pre-update
virsh snapshot-delete web01 --current

Before deleting a VM that has snapshots, virsh undefine needs --snapshots-metadata; check snapshot-list first so you know what you are discarding.

Cloning with virt-clone

virt-clone copies the disk images of an existing VM and defines a new guest with the same virtual hardware, generating a new name, UUID and MAC addresses. The source VM must be shut off.

virsh shutdown web01
virsh domstate web01            # wait for: shut off

virt-clone --original web01 --auto-clone
# or choose name and disk path yourself
virt-clone --original web01 --name web02 \
  --file /var/lib/libvirt/images/web02.qcow2

If the source has several disks, repeat --file once per disk. Use --print-xml to preview the new definition. Avoid --replace unless you mean it: it destroys and undefines an existing VM with the target name.

What a clone does not change

The virt-clone manual is clear that it does not change anything inside the guest OS. The clone still has the original’s hostname, SSH host keys, machine ID, static IP settings and any registration. Two such VMs on one network cause conflicts. Fix this before putting the clone into service, either by hand or with virt-sysprep from the libguestfs tools, which the virt-clone manual points to for this job.

Lightweight copies of a single disk

For a disk in a libvirt storage pool you can also copy just the volume with virsh vol-clone web01.qcow2 web03.qcow2 --pool default and then build a new VM around it with virt-install --import.

Official documentation

• libvirt snapshot XML format
• virsh manual page (libvirt.org)
• virt-clone manual (virt-manager project)