<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 11, 2013 at 1:06 AM, Kashyap Chamarthy <span dir="ltr"><<a href="mailto:kchamart@redhat.com" target="_blank">kchamart@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Heya,<br>
<br>
(You might want to grab a cup of coffee, it's a bit long read. Let's<br>
see if I can hold attention :) )<br>
<br>
Context:<br>
--------<br>
<br>
The word "snapshots" is quickly becoming meaningless, given vairous<br>
contexts that it can be used. I'm writing this email to get some<br>
understanding on how much OpenStack cares about snapshots (given you can<br>
create/destroy/scale guest config on the fly).<br>
<br>
<br>
Libvirt/QEMU snapshots refresher:<br>
---------------------------------<br>
<br>
In Libvirt/QEMU world, there are several flavours of snapshots possible.<br>
<br>
1) Internal Snapshots, can be further categorized as:<br>
<br>
1.1. Internal 'disk snapshot' -- {live/offline}<br>
1.2. Internal 'system checkpoint' -- {live}<br>
<br>
Single qcow2 file holds everything: original & its delta. The<br>
original file /must/ be a QCOW2 file. Pain point - The guest must be<br>
_paused_ for more than a couple of seconds while the snapshot is<br>
being taken.<br>
<br>
<br>
2) External Snapshots, can be further categorized as:<br>
<br>
2.1. External 'disk snapshot' -- {live/offline}. IOW: snapshot of the<br>
disk is saved in one file, and the delta since the snapshot is<br>
tracked in a new qcow2 file.<br>
<br>
NOTES:<br>
- Libvirt uses QEMU's 'transaction' command under the hood, when<br>
the guest is 'live.<br>
- Libvirt uses QEMU's 'qemu-img' command under the hood when the<br>
guest is 'offline'<br>
<br>
2.2. External 'system checkpoint' -- {live}. IOW: the guest's<br>
disk-state will be saved in one file, its RAM & device-state<br>
will be saved in another new file.<br>
<br>
Uses QCOW2 *overlays*: everytime a snapshot is taken, the current<br>
disk becomes a 'backing file' & a _new_ QCOW2 overlay is created to<br>
track the 'delta' (i.e. live changes). Original can be anything:<br>
block device, LVM, raw/qcow2 file, etc. Snapshot creation is<br>
instantaneous. Pain point: multiple files to track; revert/delete is<br>
a little tricky. However, this can be alleviated by<br>
merging/shortening 'snapshot chain' using libvirt/QEMU's block<br>
mechanisms -- "blockpull/blockcommit/blockcopy".<br>
<br>
<br>
3) 'system checkpoint' meaning -- it captures VM state and disk state.<br>
<br>
3.1. VM state: captures memory and device state (but not<br>
"disk" state).<br>
<br>
<br>
Questions:<br>
----------<br>
<br>
>From the above, what kind of snapshots are relevant in the context of<br>
OpenStack? Do people care much about them in cloud infrastructures?<br>
<br>
Currently, I've only played with "nova image-create", reading its<br>
code, it appears to use a combination of "virsh managedsave" + image<br>
conversion to create a new image.<br>
<br>
Then there's "cinder snapshot-create", which I'm yet to try out.<br>
<br>
Very curious to hear your thoughts/comments.<br>
<br>
All apologies (you could disregard this email) if this was already<br>
discussed elsewhere. Please point me to it.<br>
<br>
PS: I come from an understanding of libvirt/virsh/qemu land, still<br>
learning my ropes here, please bear with me :)<br>
<br>
<br>
Examples<br>
--------<br>
<br>
1/ Create a disk-only internal snapshot<br>
<br>
$ virsh snapshot-create-as f17vm1 snap1 snap1-desc<br>
<br>
2/ Create external disk-only snapshot (while the guest is *running*)<br>
<br>
$ virsh snapshot-create-as f18-base snap1 "snap1-desc" \<br>
--disk-only --atomic<br>
<br>
[or, more fine grained]<br>
<br>
$ virsh snapshot-create-as --domain f18-base \<br>
snap1 snap1-desc --disk-only \<br>
--diskspec vda,snapshot=external,file=/export/vmimages/sn1-of-f18-base.qcow2 \<br>
--atomic<br>
<br>
3/ VM State (Save the guest's memory state to a file, and restore from<br>
the same state on next restart)<br>
<br>
$ virsh managedsave fedora18<br>
<br>
4/ External system checkpoint -<br>
<a href="http://kashyapc.fedorapeople.org/virt/external-system-checkpoint-snapshot.txt" target="_blank">http://kashyapc.fedorapeople.org/virt/external-system-checkpoint-snapshot.txt</a><br>
<span class=""><font color="#888888"><br>
<br>
--<br>
/kashyap<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div><div class="gmail_extra" style>With respect to Cinder snapshots, there tends to be varying debates on this. Thread [1] is from the last time we hashed this out on the ML. Since then we've implemented a number of things in Cinder:</div>
<div class="gmail_extra" style>1. Clone (create duplicate volume, which for some uses a snapshot as an intermediate step in their implementation)</div><div class="gmail_extra" style>2. Backup (*real* long term durable backups that are independent of a snapshot currently sent to Swift)</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>And I have revert in the new LVM driver code that maybe I'll actually get back to finishing and submitting this week :)</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>A point of contention for a number of folks is that currently the base implementation is such that the snapshot is dependent on the source volume, but not all back-ends require this. Some would like to see us make this behavior optional, but my argument has always been that I'd prefer to have the consistency around what a snapshot is rather than allow every back-end to implement something different.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>From my viewpoint, if you want a true clone or backup, then create a true clone or backup.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
Not sure if this helps or not, but hopefully it may clear up some of your questions about Cinder Snapshots.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>[1] <a href="http://www.gossamer-threads.com/lists/openstack/dev/21105">http://www.gossamer-threads.com/lists/openstack/dev/21105</a></div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>John</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style><br></div></div>