On 09/11/2015 06:45 AM, Jérôme wrote:
AFAIU, live backups using libvirt may be done thanks to blockcommit as explained here on the wiki [2].
-> Considering our use case, is this the recommended way?
Yes, using active block-commit is the ideal way to perform a live backup.
Assuming yes, here is the plan.
I wrote a script that does
# Create snapshot virsh snapshot-create-as --domain $VM_NAME snap --diskspec vda,file=$VM_DIR/"$VM_NAME"-snap.qcow2 --disk-only --atomic --no-metadata --quiesce
# Copy frozen backing file cp $VM_DIR/"$VM_NAME".qcow2 $SNAP_FILEPATH
# Blockcommit snapshot back into backing file virsh blockcommit $VM_NAME vda --active --pivot
# Remove snapshot file rm $VM_DIR/"$VM_NAME"-snap.qcow2
Yep, that about covers it. Note that the --quiesce step in snapshot creation requires qemu-guest-agent running in the guest, and that you trust interaction with your guest.
I understand that this method only saves disk states, so the VM will be started as if it had been powered-off suddenly while running (not quite: thanks to the '--quiesce' option, at least the disks are in a sane state). Not perfect but better than nothing. Those backups are meant to be used only when all else failed, anyway, it's not daily use.
Yep.
-> Does this make sense? Am I missing a feature or even a different approach that would make things simpler or more secure? Am I using libvirt snapshots for what they're not meant to?
No, you're spot on for one of the useful use cases of snapshots.
-> Anything wrong about my snapshot-create-as and blockcommit command lines? May I remove the snapshot with only a rm command?
Looks correct to me, and matches my recent KVM Forum slides: http://events.linuxfoundation.org/sites/events/files/slides/2015-qcow2-expan...
Now, a few side questions, as I might have messed up with the VM I was experimenting with.
I used the same command lines as described above, except I didn't pass the '--no-metadata' option. Once the backing file was copied, I deleted the snapshot qcow2 file and thought I was done with it, until I realized the snapshot was still listed by virsh snapshot-list. And I couldn't find a way to delete it. (For the record, I asked on serverfault about that [3].)
virsh snapshot-delete --metadata $dom $badname to remove $badname snapshot that no longer exists because you changed things behind the scenes.
Ultimately, I found the snapshot's .xml descriptor and deleted it (in fact, moved it) while libvirtd was down. Now, the snapshot is not listed anymore.
-> Am I getting away with it? Are there still some traces about that snapshot? Is my VM in an unsafe state? Anything I should do about it?
Directly manipulating .xml files behind libvirt's back is not ideal; better is to use libvirt APIs (the way snapshot-delete --metadata does).
-> What would be the proper way of dropping an external snapshot that was created without the '--no-metadata' option, then blockcommitted? I understand libvirt doesn't do it yet.
Thanks for any hint. I naively thought our use case was pretty usual, and I must admit I didn't think I'd have to dive into this complexity, which is why I'm thinking there might be a more "common" way...
Nope, right now, there is still some user burden rather than a one-command-does-it-all virsh wrapper. But fortunately it is not too bad (you proved it is scriptable), and you discovered the correct sequencing. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org