Open Stack

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