Open Stack

On Tue, Jun 11, 2013 at 1:06 AM, Kashyap Chamarthy <kchamart at redhat.com>wrote:

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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:
1. Clone (create duplicate volume, which for some uses a snapshot as an
intermediate step in their implementation)
2. Backup (*real* long term durable backups that are independent of a
snapshot currently sent to Swift)

And I have revert in the new LVM driver code that maybe I'll actually get
back to finishing and submitting this week :)

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.

>From my viewpoint, if you want a true clone or backup, then create a true
clone or backup.

Not sure if this helps or not, but hopefully it may clear up some of your
questions about Cinder Snapshots.

[1] http://www.gossamer-threads.com/lists/openstack/dev/21105

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130611/26a440ee/attachment.html>