Re: [libvirt-users] Can I move the disk image of the guest while it is running?

From: "Eric Blake" <eblake(a)redhat.com&gt; To: "Andrew Martin" <amartin(a)xes-inc.com&gt; Cc: "Gergely Horváth" <gergely.horvath(a)inepex.com&gt;, libvirt-users(a)redhat.com Sent: Thursday, February 6, 2014 2:35:35 PM Subject: Re: [libvirt-users] 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(a)redhat.com&gt; >> To: "Andrew Martin" <amartin(a)xes-inc.com&gt; >> Cc: "Gergely Horváth" <gergely.horvath(a)inepex.com&gt;, >> libvirt-users(a)redhat.com >> Sent: Thursday, February 6, 2014 9:31:29 AM >> Subject: Re: [libvirt-users] 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.