The 15/03/13, Eric Blake wrote:
On 03/15/2013 06:17 AM, Nicolas Sebrecht wrote:
Here are the basics steps. This is still not that simple and there are tricky parts in the way.
Usual workflow (use case 2) ===========================
Step 1: create external snapshot for all VM disks (includes VM state). Step 2: do the backups manually while the VM is still running (original disks and memory state). Step 3: save and halt the vm state once backups are finished. Step 4: merge the snapshots (qcow2 disk wrappers) back to their backing file. Step 5: start the VM.
This involves guest downtime, longer according to how much state changed since the snapshot.
Right.
Restarting from the backup (use case 1) =======================================
Step A: shutdown the running VM and move it out the way. Step B: restore the backing files and state file from the archives of step 2. Step C: restore the VM. (still not sure on that one, see below)
I wish to provide a more detailed procedure in the future.
With new enough libvirt and qemu, it is also possible to use 'virsh blockcopy' instead of snapshots as a backup mechanism, and THAT works with raw images without forcing your VM to use qcow2. But right now, it only works with transient guests (getting it to work for persistent guests requires a persistent bitmap feature that has been proposed for qemu 1.5, along with more libvirt work to take advantage of persistent bitmaps).
Fine. Sadly, my guests are not transient.
Guests can be made temporarily transient. That is, the following sequence has absolute minimal guest downtime, and can be done without any qcow2 files in the mix. For a guest with a single disk, there is ZERO! downtime:
virsh dumpxml --security-info dom > dom.xml virsh undefine dom virsh blockcopy dom vda /path/to/backup --wait --verbose --finish virsh define dom.xml
For a guest with multiple disks, the downtime can be sub-second, if you script things correctly (the downtime lasts for the duration between the suspend and resume, but the steps done in that time are all fast):
virsh dumpxml --security-info dom > dom.xml virsh undefine dom virsh blockcopy dom vda /path/to/backup-vda virsh blockcopy dom vdb /path/to/backup-vdb polling loop - check periodically until 'virsh blockjob dom vda' and 'virsh blockjob dom vdb' both show 100% completion virsh suspend dom virsh blockjob dom vda --abort virsh blockjob dom vdb --abort virsh resume dom virsh define dom.xml
In other words, 'blockcopy' is my current preferred method of online guest backup, even though I'm still waiting for qemu improvements to make it even nicer.
As I understand the man-page, blockcopy (without --shallow) creates a new disk file of a disk by merging all the current files if there are more than one. Unless --finish/--pivot is passed to blockcopy or until --abort/--pivot/--async is passed to blockjob, the original disks (before blockcopy started) and the new disk created by blockcopy are both mirrored. Only --pivot makes use of the new disk. So with --finish or --abort, we get a backup of a running guest. Nice! Except maybe that the backup doesn't include the memory state. In order to include the memory state to the backup, I guess the pause/resume is inevitable: virsh dumpxml --security-info dom > dom.xml virsh undefine dom virsh blockcopy dom vda /path/to/backup-vda polling loop - check periodically until 'virsh blockjob dom vda' shows 100% completion virsh suspend dom virsh save dom /path/to/memory-backup --running virsh blockjob dom vda --abort virsh resume dom virsh define dom.xml I'd say that the man page miss the information that these commands can run with a running guest, dispite the mirroring feature might imply it. I would also add a "sync" command just after the first command as a safety mesure to ensure the xml is kept on disk. The main drawback I can see is that the hypervisor must have at least as free disk space than the disks to backup... Or have the path/to/backups as a remote mount point. Now, I wonder if I change of backup strategy and make the remote hosting the backup mounted locally on the hypervisor (via nfs, iSCSI, sshfs, etc), should I expect write performance degradation? I mean, does the running guest wait for underlying both mirrored disk write (cache is set to none for the current disks)? -- Nicolas Sebrecht