[libvirt-users] Live snapshots of a single block device

[Andrew Martin]

> >> --live only makes sense when mixed with memory snapshots (with --memspec);
> >> but
> >> as you are doing a --disk-only snapshot, it doesn't help (I'm not sure if
> >> it
> >> will error out as mutually exclusive or just be silently ignored,
> >> without reading the code).
> > I'm using this code in a script for creating live backups of VMs - would it
> > make
> > sense to include --memspec to capture the memory state so that an fsck on
> > boot
> > isn't necessary? I remember you explained --quiese awhile back:
> > https://www.redhat.com/archives/libvirt-users/2013-February/msg00020.html
> 
> --memspec and --quiesce are orthogonal, you only need one or the other
> (in fact, they do NOT work together in the current implementation).
> --memspec says to capture the domain memory state (migrate to file;
> using --live additionally says to minimize the time the guest is paused
> but the file may be larger), and when the guest pauses at the end of
> that migration, then snapshot the disks.  By resuming the guest from
> that migration stream and disk state, any pending I/O operations in
> flight in the guest OS will still be ready to go when the guest starts
> back up, no fsck needed.  --quiesce says to tell the guest to flush all
> I/O, then captures disk state, all without stopping the guest.  But
> --quiesce requires the guest to be running to work, while --memspec
> forceably stops the guest (the migration algorithm must pause, even if
> --live minimizes the pause to a fraction of a second).
Would calling snapshot-create-as with --disk-only and --quiese still succeed
on a VM that is stopped (since the disk would already be consistent, it would
just call "qemu-img create")?

> 
> > 
> > However I don't have qemu-guest-agent installed on the guests, so would
> > using
> > --memspec instead of --disk-only produce a snapshot that is consistent
> > (since it
> > would "resume" with the same memory state) or would this not be ideal
> > for backups (e.g easy to restore/recover)? Can the memory image be written
> > to
> > the same image file (qcow2) as the disk snapshot?
> 
> External checkpoints (those where --memspec was used) have more
> information than disk-only snapshots (even if --quiesce was used to
> minimze the need for an fsck on the disk contents).  Thus, --memspec
> snapshots require no guest cooperation, at the expense of requiring more
> disk space to hold the state.  On the other hand, if you are going to do
> a --memspec snapshot, I _highly_ recommend that you snapshot ALL disks
> at once, rather than trying to do just one disk at a time.  With
> --disk-only (whether or not you use --quiesce), all you can recover is
> the disk state by a fresh boot of the disk (--quiesce minimizes the
> chance that the fresh boot needs an fsck).  But with --memspec, the
> memory state is only consistent if it matches ALL disk state taken at
> the same time as the memory state - if you omit a disk, then try to
> revert to that memory state, your running guest will behave as if the
> disk instantaneously corrupted data out of underneath the OS.
It sounds like --quiese would work better for my use case, since I'm only
concerned with keeping the disk state consistent and prefer to not stop
the guest (even for a fraction of a second). The qemu-kvm 1.4.0 package
I built includes a version of qemu-guest-agent 1.4.0, so I will start
testing after installing it in a guest and adding the XML to the config:
http://wiki.libvirt.org/page/Qemu_guest_agent

Thanks!

Andrew