Re: [libvirt-users] Managing Live Snapshots with Libvirt 1.0.1

On 02/04/2013 02:37 PM, Andrew Martin wrote: --quiesce says to send a message on the qemu-guest-agent to tell the guest to get its file systems into a consistent state. For it to be useful, you have to: 1. trust your guest (anything that involves guest cooperation can backfire if you don't trust the guest) 2. have the qemu-guest-agent channel wired up in the guest XML (there's a request to make this easier to do; but for now, http://libvirt.org/formatdomain.html#elementCharChannel documents how to set up org.qemu.guest_agent.0) 3. have the guest agent actually running in the guest (so far, it has been ported to at least Windows and Linux, but as recently as Fedora 18, I raised a bug that the default live image build was not installing the guest agent by default. If your guest is running some other OS, then you will probably have to contribute patches to the qemu list to port the guest agent to your choice of guest) Additionally, if you use the guest agent from (not yet released) qemu 1.4 or later, there was a recent addition in upstream qemu that added hooks so you could add additional wrapper actions (such as a database quiesce command) around the agent commands that freeze and rethaw all file systems, for even more stability in the snapshot image. Using --quiesce is therefore optional; if you use it, you are more likely to be able to boot your guest from the snapshot point in time without having inconsistent file systems; if you do not use it, you are more likely to have to run fsck or similar to recover files that were in the middle of being modified at the time of the snapshot (since a disk-only snapshot doesn't include guest RAM state). Meanwhile, with libvirt 1.0.1 and later, an external snapshot including RAM does not support the --quiesce option, for two reasons: 1. --quiesce requires that the guest be running in order to freeze its own file systems, but taking a snapshot of memory at the same time as a snapshot of the disks requires pausing the guest (even if the downtime is limited to the sub-second range by use of the --live flag). 2. if you have the RAM state available, then you have not lost any in-flight I/O operations that were in the guest RAM, so it is no longer quite as essential as it was for disk-only snapshots to get the disks into a stable state. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org