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-expanded.pdf > > 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
