If you have a VMWare-Background, handling libvirt-snapshots is very counter-intuitive. With VMWare, you take a snapshot and make changes to the actual disk. So when you’re done and haven’t encountered any problems, you just delete the snapshot and be happy.
With libvirt it’s the other way around: You work with the snapshot! This means you have to commit the changes to the base image after making changes! If you just delete the snapshot you’re back where you started! To make things worse, there are internal and external snapshots, and the latter aren’t fully supported by libvirt, meaning you can’t delete external snapshots with virsh.
So, to “emulate” VMWare-Behavior you have to:
- Create an external snapshot while the VM is shut down:
# snapshot-create-as <domain> <snapshot-name> --disk-only --atomic
- start the VM again:
# start <domain>
Don’t let you fool by the output of snapshot-list: even though it says that the domain is shutoff, you’re actually working with the snapshot!
- Make your changes
- Once you’re done, commit the changes to the base image. Since libvirt cannot handle external snapshots properly you have to do it by foot. Shut down the VM and go to the directory with the disk images (/var/lib/libvirt/images or such). Then commit the changes to the base image with qemu-img:
# qemu-img commit <filename-of-external-snapshot>
Don’t worry about the destination. It’s in the metadata of the snapshot. Repeat for every disk of the VM and remove the (now very small) snapshot files.
- Unfortunately libvirt still thinks that there is a snapshot. Delete it with
# snapshot-delete <domain> --metadata <name-of-snapshot>
- More unfortunately, libvirt still references the snapshot files as base for the virtual disks. So remove them, re-add the real ones and start the VM.
Well, maybe it’s easier with internal snapshots (it should, because the procedure above is quite a dance…), but it works.