The 20/03/13, Eric Blake wrote:
On 03/18/2013 05:39 AM, Nicolas Sebrecht wrote:
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.
Sure, I wish to write one but I'm very busy these days. Will do my best.
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.
Don't know NBD very well but I'll investigate on it. Thanks for the input.
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.
Ok. Thank you very much Eric for this whole thread and your efforts in giving me all these information I was missing. Very appreciated. -- Nicolas Sebrecht