libvirt users - May 2014 - Re: Live snapshots of a single block device

> >> --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

On 05/23/2014 12:16 PM, Andrew Martin wrote:
>> --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")?
For an offline guest, --disk-only makes no difference (there is no
memory to worry about); and you are correct that the disk is consistent
(assuming the OS has a clean shutdown before going offline).  Yes,
calling 'qemu-img create' is basically what libvirt does for an offline
external snapshot.

However, a paused/stopped guest cannot respond to a quiesce request (the
guest agent only works if the guest is running), so your attempt to use
--quiesce would fail; you'd have to omit the parameter if the guest is
stopped.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

----- Original Message -----
> From: "Eric Blake" <eblake@redhat.com>
> To: "Andrew Martin" <amartin@xes-inc.com>
> Cc: libvirt-users@redhat.com
> Sent: Friday, May 23, 2014 7:30:44 PM
> Subject: Re: [libvirt-users] Live snapshots of a single block device
> 
> On 05/23/2014 12:16 PM, Andrew Martin wrote:
> 
> >> --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")?
> 
> For an offline guest, --disk-only makes no difference (there is no
> memory to worry about); and you are correct that the disk is consistent
> (assuming the OS has a clean shutdown before going offline).  Yes,
> calling 'qemu-img create' is basically what libvirt does for an
offline
> external snapshot.
> 
> However, a paused/stopped guest cannot respond to a quiesce request (the
> guest agent only works if the guest is running), so your attempt to use
> --quiesce would fail; you'd have to omit the parameter if the guest is
> stopped.
Okay, that makes sense to me. Thanks for the clarification!

Andrew