5:33 p.m.
On 03/18/2013 05:39 AM, Nicolas Sebrecht wrote:
The 15/03/13, Eric Blake wrote:
> On 03/15/2013 06:17 AM, Nicolas Sebrecht wrote:
> 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.
Correct.
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.
Indeed, sounds like room for a future addition to libvirt, if qemu 1.5
gives us the additional hooks that I'd like to have. In particular,
there is talk on the upstream qemu list about adding a blockbackup
operation that would make capturing memory state and starting a backup
job easier to manage than the current approach of starting a mirroring
job, then capturing memory state and ending the mirroring job.
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
A live-migration solution would have less downtime, but potentially take
up more disk space. Again, there is talk on the upstream qemu list
about how to optimize the amount of disk space taken by a live migration
to a seekable file.
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.
Care to write a patch? The virsh man page is generated from
libvirt.git:tools/virsh.pod.
I would also add a "sync" command just after the first command as a
safety mesure to ensure the xml is kept on disk.
Again, if libvirt can be improved to do better external snapshot
management, a sync of the xml/memory state file should be part of this
effort.
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.
Yes, but that's true of any backup operation - you are committing to the
disk space for both the live and the backup, in some form or another.
Also, disk mirroring to a remote point is fairly easy to set up, by
using nbd:... instead of /path/to/file as the destination for the
blockcopy, and having an NBD server listening on the remote destination
side.
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)?
Probably a question better asked on the qemu list, but yes, my
understanding is that if you have a disk mirror or backup job set up,
then qemu has to manage to flush I/O to two locations instead of one,
and might end up slightly slowing the guest as a result.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org