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