10:05 a.m.
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-ex...
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