----- Original Message ----- > From: "Eric Blake" <eblake@xxxxxxxxxx> > To: "Andrew Martin" <amartin@xxxxxxxxxxx> > Cc: "Gergely Horváth" <gergely.horvath@xxxxxxxxxx>, libvirt-users@xxxxxxxxxx > Sent: Thursday, February 6, 2014 2:35:35 PM > Subject: Re: Can I move the disk image of the guest while it is running? > > On 02/06/2014 01:25 PM, Andrew Martin wrote: > > ----- Original Message ----- > >> From: "Eric Blake" <eblake@xxxxxxxxxx> > >> To: "Andrew Martin" <amartin@xxxxxxxxxxx> > >> Cc: "Gergely Horváth" <gergely.horvath@xxxxxxxxxx>, > >> libvirt-users@xxxxxxxxxx > >> Sent: Thursday, February 6, 2014 9:31:29 AM > >> Subject: Re: Can I move the disk image of the guest while > >> it is running? > >> > >> On 02/06/2014 08:14 AM, Andrew Martin wrote: > >>> Eric, > >>> > >>> For scripted live backups, which non-transient technique would you > >>> prefer: > >>> 1. snapshot-create-as followed by blockpull, which results in the > >>> original > >>> file being left as a standalone copy of the VM from that point in time; > >>> it > >>> can then be copied off to a backup disk once blockpull completes > >> > >> Slower (because it pulls the entire contents of the original file into > >> the new file), but likely to succeed. > > Is there a faster, non-transient way to do this with the current versions > > of qemu and libvirt? > > Sadly, no. The whole area of block chain management is still undergoing > active development, and qemu 2.0 definitely adds some nice features to > the mix that libvirt will have to be taught to support. > > > > >> > >>> 2. snapshot-create-as followed by copying the backing file (since it is > >>> now > >>> read-only) and then using blockcommit to pull the interim changes back > >>> into > >>> the original/backing file (and removing the snapshot file) > >> > >> Ideal, but not supported until (unreleased) qemu 2.0. > >> > > Ah, does blockcommit currently only work with offline VMs with qemu 1.x? > > Blockcommit does not yet work with offline VMs. But you can get the > same behavior as what offline blockcommit would do by using qemu-img > manually. One idea for a patch is to see if 'qemu -M none' can drive a > block commit operation using a long-running qemu process that does > nothing but the block operation; if that works, then we could wire up > libvirt to do long-running block operations that survive a libvirtd > restart. But the reason libvirt doesn't currently support offline > operations is that we have no way to keep a long-running qemu-img > operation running smoothly across a libvirtd restart. Thanks for the clarification! Andrew _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
