.. NOTE: This notes is as of 1-Nov-2012. This information needs to be re-visited
   as libvirt/qemu gets more updates.

Internal Snapshots
==================
    - Pros:
        (1) Single file holds everything, including the orignial & its delta. Very
            useful for moving around machines.

    - Cons:
        (1) Qemu doesn't test it very much, and it shows, with poor performance.

        (2) The guest is paused for seconds or even minutes while taking the
            snapshot.

        (3) There is no way to access the data at the time of the snapshot while
            qemu is running (although this feature has been requested of qemu,
            no one has yet indicated that they plan to implement it any time
            soon).
    

External Snapshots
==================
    - Pros:
        (1) You can do read-only operations on the data at the time of the
            snapshot even while qemu continues to run.

        (2) Currently very well tested, and qemu continues to enhance what is
            supported.

        (3) The guest is paused for less than a second while taking the snapshot.

    - Cons:
        (1) You now have multiple files to track, so tasks like reverting and
            cloning become more difficult to conceptually manage (but even here,
            libvirt is trying to add code to eventually get to the point where
            we can guarantee that any commit, pull, revert, or other snapshot
            operation on one file managed by libvirt will be prevented if any
            other file would be corrupted by the change, rather than the current
            state of things of letting you shoot yourself in the foot. (as of
            10-OCT-2012).


BlockPull:
==========

Populates a disk image from its backing file.

If 'base' is specified for blockpull, the disk image(the current 'active') will
be populated from its backing image chain up to 'base' image. (and makes it
the backing file for 'active').

If 'base' is not specified for blockpull, the disk image(the 'active') will
become a standalone image, by populating data from all its backing files.

Common use case
---------------
- Live Backup

    - Create a snapshot
        # virsh snapshot-create-as myvm snapshot1 "snapshot1 description"
        --disk-only --atomic

    - Backup the original storage/disk image

    - Merge the disk changes accumulated in the snaphshot back with the original
      disk. (note: since the --base path is not provided, the original disk
      image will become a standalone image. (and blockpull needs to be done for
      every disk image that was snapshotted)

        # virsh blockpull --domain myvm --path /var/lib/libvirt/images/myvm.snapshot1


Current limitations & things to consider:
-----------------------------------------
 
    (1) blockpull can only pull into the *active* layer.
        - Support to pull into an intermediate/arbitrary layer is in progress.

        - NOTES:
               -  Pulling into intermediate images requires opening the
                  intermediate file read/write, as well as ensuring that any
                  reads done in the active layer get correct data.

       
               -  Case of 'reading data' -- In the chain base <- snap1 <- active
                  if you pull base into snap1, reading active has to know whether the
                  data comes from base or from snap1 . But if you pull into
                  active, you already have the destination read/write, and once
                  the data is pulled, you don't have to worry about keeping the chain 
                  consistent.
                  

               -  Case of 'writing data' -- If you pull into the active layer,
                  then a write eliminates the need to pull that cluster from the
                  backing file, thanks to copy-on-write semantics. But, if you
                  pull into an intermediate layer, a write at the active layer
                  doesn't affect the fac t that you still have to pull into the
                  intermediate layer. Even though the active layer won't use
                  that cluster from the intermediate layer.

       (2) At the moment, virsh blockpull cannot be done 'offline' (although,
           'qemu-img' can do that.)



BlockCommit:
============

Current limitations & things to consider:
----------------------------------------

    - At the moment, with blockcommit, it's not possible(yet) to merge down the
      current 'active' layer into the backing files.
 

On Reverting
============
with Qemu 1.2, Live backups with 'disk-snapshots' is possible. But. we have to
request the guest file system to freeze if you want to be able to revert to the
snapshot without having to fsck it.