> >> --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 _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
