[libvirt-users] Managing Live Snapshots with Libvirt 1.0.1

[Andrew Martin]

----- Original Message -----
> From: "Eric Blake" <eblake at redhat.com>
> To: "Andrew Martin" <amartin at xes-inc.com>
> Cc: libvirt-users at redhat.com
> Sent: Friday, February 1, 2013 3:23:03 PM
> Subject: Re: [libvirt-users] Managing Live Snapshots with Libvirt 1.0.1
> 
> On 02/01/2013 11:12 AM, Andrew Martin wrote:
> >> Are you using the --disk-only and/or --memspec options when you
> >> use
> >> snapshot-create-as?  Or put another way, are your snapshots
> >> internal
> >> or external?
> > 
> > Here's the full command I've been using:
> > virsh snapshot-create-as --domain "$VM_NAME" --name "$SNAP_NAME"
> > --disk-only --atomic
> 
> That's external.
> 
> > 
> > Can you elaborate on the difference between internal and external
> > snapshots? The snapshots I created with the above command are
> > contained
> > in separate qcow2 backing files, which I would think to be
> > external, but
> > snapshot-info shows them as internal?
> 
> Any snapshot created without --disk-only and without --memspec is
> internal - it resides completely within an existing qcow2 image (no
> new
> files are created).  All snapshots with --disk-only or --memspec are
> external; the domain state is now spread across multiple files.
> 
> If snapshot-info shows a --disk-only snapshot as internal, then
> that's a
> bug, and we need to fix it.  What version of libvirt did you test?
> 

I was using 1.0.1. I'm unable to reproduce this now so I guess it
isn't a concern.

> > 
> >>From what I can see there are 3 different types of snapshots:
> > 1. internal (offline) qcow2 snapshots created with qemu-img
> > snapshot
> > 2. external (live) snapshots with --disk-only
> > 3. external (live) snapshots with --memspec and/or --diskspec
> > 
> > Or, am I misunderstanding what --disk-only and --diskspec do?
> 
> There's actually:
> 
> 1. internal offline: internal qcow2 snapshots (disk-only) created
> with
> 'snapshot-create-as' with no flags for offline guest [wired to
> 'qemu-img
> snapshot' under the hood]
> 2. internal online: internal qcow2 snapshots (disk and memory)
> created
> with 'snapshot-create-as' with no flags for online guest [wired to
> qemu
> 'savevm' HMP command]
> 3. external offline: qcow2 wrapper around any base file type, created
> with 'snapshot-create-as --disk-only' for offline guest [wired to
> 'qemu-img create']
> 4. external online disk-only: qcow2 wrapper around any base file
> type,
> created with 'snapshot-create-as --disk-only' for online guest [wired
> to
> qemu 'transaction' QMP command]
> 5. external online memory: qcow2 wrapper around any base file type
> plus
> migration to file, created with 'snapshot-create-as --memspec' for
> online guest [wired to qemu 'migrate' and 'transaction' QMP commands]
> 6. external memory only: migration to file, created with 'virsh save'
> for online guest [wired to qemu 'migrate' QMP command]
> 
> There's also talk on the upstream qemu list about making even more
> options for snapshots (for example, 'savevm' is too bulky for
> creating
> internal qcow2 snapshots, so the goal is to allow for an internal
> qcow2
> snapshot without also grabbing guest memory; also, live migration to
> file is a waste of disk space on a guest that takes a long time to
> converge, so a new file format for storing guest memory would make
> live
> snapshots take less disk space).

Thanks for this clarification. When taking live snapshots, what does
the --quiesce option do exactly? Does it call a sync on the guest to
make sure the disks are in a consistent state? If so, does it only work
for specific drivers, e.g. VirtIO disks? Would it be best to use this
option when taking live snapshots to ensure that the snapshot disk is
consistent?

> 
> >> For internal snapshots, it should just work; when reverting, it
> >> shouldn't matter whether the domain is live or shutdown, because
> >> you are going to change state anyway.  Internal snapshots are not
> >> invalidated (the way qcow2 works, each internal snapshot
> >> increments a
> >> reference counter on all clusters in use at the time of the
> >> snapshot,
> >> with no intrinsic relation between snapshots; executing from the
> >> point
> >> of a given snapshot does a copy-on-write allocation for any
> >> cluster
> >> with a reference count larger than 1).
> > 
> > Since they are separate copy-on-write snapshots, this means I could
> > revert to snap1, make changes, and then later revert to snap3?
> 
> For internal snapshots, yes.  For external snapshots, the act of
> reverting is not yet wired up nicely in libvirt 1.0.2; basically,
> doing
> a revert of an external snapshot needs to decide whether to create
> another snapshot (by adding an atomic revert-and-create action), or
> to
> invalidate all existing snapshots that descend below the point being
> reverted to.
> 
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 
> 

Thanks,

Andrew