[转] Snapshotting with libvirt for qcow2 images
http://kashyapc.com/2011/10/04/snapshotting-with-libvirt-for-qcow2-images/
Libvirt 0.9.6 was recently out. Take a look at 0.9.5 changelog for truckload of features/bugfixes/cleanups(specifically snapshot related) from the libvirt team.
So, I grabbed the F14 srpm from Libvirt ftp, and made a quick Fedora koji scratch build of libvirt-0.9.6 for Fedora 15 and gave the snapshot features a whirl. Here it goes:
(Also noted below is some very useful discussion I had(on #virt, OFTC) with Eric Blake (Upstream/Red Hat’s Libvirt dev, very friendly guy.) on snapshots. It was way informative not to capture it.)
Context on types of snapshots
At the moment, snapshotting in KVM/QEMU/Libvirt land is supported primarily for QCOW2 disk images. I briefly discussed about Qcow2 previously here.
There are several different types of snapshots possible. Some idea on that:
Internal snapshot: A type of snapshot, where a single QCOW2 file will hold both the ‘saved state’ and the ‘delta’ since that saved point. ‘Internal snapshots’ are very handy because it’s only a single file where all the snapshot info. is captured, and easy to copy/move around the machines.
External snapshot: Here, the ‘original qcow2 file’ will be in a ‘read-only’ saved state, and the new qcow2 file(which will be generated once snapshot is created) will be the delta for the changes. So, all the changes will now be written to this delta file. ‘External Snapshots’ are useful for performing backups. Also, external snapshot creates a qcow2 file with the original file as its backing image, and the backing file can be /read/ in parallel with the running qemu.
VM State: This will save the guest/domain state to a file. So, if you take a snapshot including VM state, we can then shut off that guest and use the freed up memory for other purposes on the host or for other guests. Internally this calls qemu monitor’s ‘savevm’ command. Note that this only takes care of VM state(and not disk snapshot). To try this out:
#------------------------------------------------
# Memory before saving the guest f15vm3
$ free -m
total used free shared buffers cached
Mem: 10024 5722 4301 0 164 4445
-/+ buffers/cache: 1112 8911
Swap: 0 0 0
#------------------------------------------------
$ virsh list
Id Name State
----------------------------------
5 f15guest running
6 f15vm3 running
#------------------------------------------------
# Save the guest f15vm3 to a file 'foof15vm3'
$ virsh save f15vm3 foof15vm3
Domain f15vm3 saved to foof15vm3
#------------------------------------------------
# Now, f15vm3 is gracefully saved/shutdown.
$ virsh list
Id Name State
----------------------------------
5 f15guest running
#------------------------------------------------
# Notice the RAM being freed
$ free -m
total used free shared buffers cached
Mem: 10024 5418 4605 0 164 4493
-/+ buffers/cache: 760 9263
Swap: 0 0 0
#------------------------------------------------
# Let's restore the guest back from the file 'foof15vm3'
$ virsh restore foof15vm3
Domain restored from foof15vm3
#------------------------------------------------
# List the status. f15vm3 is up and running.
$ virsh list
Id Name State
----------------------------------
5 f15guest running
7 f15vm3 running
#------------------------------------------------
For brevity, let’s try out internal disk snapshots where all the snapshot info. (like disk and VM state info) are stored in a single qcow2 file.
Virsh(libvirt shell interface to manage guests) has some neat options for snapshot supports. So, I’ve got an F15 guest (Qcow2 disk image).
Internal Disk Snapshots when the guest is online/running
For illustration purpose, let’s use a Fedora-15 guest called ‘f15guest’ .
$ virsh list Id Name State ---------------------------------- 4 f15guest running $
For clarity, ensure there are no prior snapshot instances around.
$ virsh snapshot-list f15guest Name Creation Time State ------------------------------------------------------------ $
Before creating a snapshot, we need to create a snapshot xml file with 2 simple elements (name and description) if you need sensible name for the snapshot. Note that only these two fields are user settable. Rest of the info. will be filled by Libvirt.
$ cat /var/tmp/snap1-f15guest.xml
<domainsnapshot>
<name>snap1-f15pki </name>
<description>F15 system with dogtag pki packages </description>
</domainsnapshot>
$
Eric Blake noted that, the domainsnapshot xml file is optional now for ‘snapshot-create’ if you don’t need a description for the snapshot. And if it’s okay with libvirt generating the snapshot name for us. (More on this, refer below)
Now, I’m taking a snapshot while the ‘guest’ is running live. Here, Eric noted that, especially when running/live, the more RAM the guest has, and the more active the guest is modifying that RAM, the longer the it will take to create a snapshot. This was a guest was mostly an idle guest.
$ virsh snapshot-create f15guest /var/tmp/snap1-f15guest.xml Domain snapshot snap1-f15pki created from '/var/tmp/snap1-f15guest.xml' $
While the snapshot-creation is in progress on the live guest, the state of the guest will be ‘paused’.
$ virsh list Id Name State ---------------------------------- 4 f15guest paused $
Once, the snapshot is created, list the snapshots of f15guest
$ virsh snapshot-list f15guest Name Creation Time State ------------------------------------------------------------ snap1-f15pki 2011-10-04 19:04:00 +0530 running $
Internal snapshot while the guest is offline
For fun, I created another snapshot, but after shutting down the guest. Now, the snapshot creation is just instantaneous.
$ virsh list Id Name State ---------------------------------- $ virsh snapshot-create f15guest Domain snapshot 1317757628 created
List the snapshots of ‘f15guest’ using virsh.
$ virsh snapshot-list f15guest Name Creation Time State ------------------------------------------------------------ 1317757628 2011-10-05 01:17:08 +0530 shutoff snap1-f15pki 2011-10-04 19:04:00 +0530 running
To see some information about the VM size, snapshot info:
$ qemu-img info /export/vmimgs/f15guest.qcow2 image: /export/vmimgs/f15guest.qcow2 file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 3.2G cluster_size: 65536 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 snap1-f15pki 1.7G 2011-10-04 19:04:00 32:06:34.974 2 1317757628 0 2011-10-05 01:17:08 00:00:00.000 $
To revert to a particular snapshot, virsh snapshot-revert domain snapshotname
Also, discussed with Eric, in what cases does virsh invoke Qemu’s ‘savevm‘ and ‘qemu-img snapshot -c‘ commands while creating different types of snapshots discussed earlier above. Here is the outline:
- it uses ‘qemu-img snapshot -c‘ if the domain is offline and –disk-only was not specified
- it uses qemu’s ‘savevm‘ if the domain is online and –disk-only was not specified
- it uses qemu’s ‘snapshot_blkdev‘ if the domain is online and –disk-only is specified
(Note: –disk-only is an option to capture only ‘disk state’ but not VM state. This option is available w/ virsh ‘snapshot-create’ or ‘snapshot-create-as’ commands.)
