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

[Eric Blake]

On 05/23/2014 08:41 AM, Andrew Martin wrote:

>>
>> Any reason you aren't upgrading to newer versions?  Although these seem
>> sufficient for what you are trying.
> The VM hosts I'm using all run Ubuntu 12.04 and I haven't had time to backport
> and test newer versions yet. I've published the latest versions I built in this
> PPA: https://launchpad.net/~xespackages/+archive/virtualization

One of the benefits of newer qemu is the ability to do point-in-time
snapshots without altering the backing chain in use by the active disk
(well, qemu 2.0 has some improvements, and unreleased qemu 2.1 has even
more in the pipeline; and it takes newer qemu to drive some of these
improvements).  Some of these new approaches may provide enough
additional efficiency over the older methods that they are worth
upgrading for - but if you can get things working to your needs with an
older version, great.

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20140523/8334d8bd/attachment.sig>