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