[openstack-dev] [Discussion] Different types of snapshots
Kashyap Chamarthy
kchamart at redhat.com
Tue Jun 11 07:06:15 UTC 2013
Heya,
(You might want to grab a cup of coffee, it's a bit long read. Let's
see if I can hold attention :) )
Context:
--------
The word "snapshots" is quickly becoming meaningless, given vairous
contexts that it can be used. I'm writing this email to get some
understanding on how much OpenStack cares about snapshots (given you can
create/destroy/scale guest config on the fly).
Libvirt/QEMU snapshots refresher:
---------------------------------
In Libvirt/QEMU world, there are several flavours of snapshots possible.
1) Internal Snapshots, can be further categorized as:
1.1. Internal 'disk snapshot' -- {live/offline}
1.2. Internal 'system checkpoint' -- {live}
Single qcow2 file holds everything: original & its delta. The
original file /must/ be a QCOW2 file. Pain point - The guest must be
_paused_ for more than a couple of seconds while the snapshot is
being taken.
2) External Snapshots, can be further categorized as:
2.1. External 'disk snapshot' -- {live/offline}. IOW: snapshot of the
disk is saved in one file, and the delta since the snapshot is
tracked in a new qcow2 file.
NOTES:
- Libvirt uses QEMU's 'transaction' command under the hood, when
the guest is 'live.
- Libvirt uses QEMU's 'qemu-img' command under the hood when the
guest is 'offline'
2.2. External 'system checkpoint' -- {live}. IOW: the guest's
disk-state will be saved in one file, its RAM & device-state
will be saved in another new file.
Uses QCOW2 *overlays*: everytime a snapshot is taken, the current
disk becomes a 'backing file' & a _new_ QCOW2 overlay is created to
track the 'delta' (i.e. live changes). Original can be anything:
block device, LVM, raw/qcow2 file, etc. Snapshot creation is
instantaneous. Pain point: multiple files to track; revert/delete is
a little tricky. However, this can be alleviated by
merging/shortening 'snapshot chain' using libvirt/QEMU's block
mechanisms -- "blockpull/blockcommit/blockcopy".
3) 'system checkpoint' meaning -- it captures VM state and disk state.
3.1. VM state: captures memory and device state (but not
"disk" state).
Questions:
----------
>From the above, what kind of snapshots are relevant in the context of
OpenStack? Do people care much about them in cloud infrastructures?
Currently, I've only played with "nova image-create", reading its
code, it appears to use a combination of "virsh managedsave" + image
conversion to create a new image.
Then there's "cinder snapshot-create", which I'm yet to try out.
Very curious to hear your thoughts/comments.
All apologies (you could disregard this email) if this was already
discussed elsewhere. Please point me to it.
PS: I come from an understanding of libvirt/virsh/qemu land, still
learning my ropes here, please bear with me :)
Examples
--------
1/ Create a disk-only internal snapshot
$ virsh snapshot-create-as f17vm1 snap1 snap1-desc
2/ Create external disk-only snapshot (while the guest is *running*)
$ virsh snapshot-create-as f18-base snap1 "snap1-desc" \
--disk-only --atomic
[or, more fine grained]
$ virsh snapshot-create-as --domain f18-base \
snap1 snap1-desc --disk-only \
--diskspec vda,snapshot=external,file=/export/vmimages/sn1-of-f18-base.qcow2 \
--atomic
3/ VM State (Save the guest's memory state to a file, and restore from
the same state on next restart)
$ virsh managedsave fedora18
4/ External system checkpoint -
http://kashyapc.fedorapeople.org/virt/external-system-checkpoint-snapshot.txt
--
/kashyap
More information about the OpenStack-dev
mailing list