Comment 13 for bug 1025244

On 01/02/2013 08:50 AM, Stefan Hajnoczi wrote:
> On Tue, Dec 18, 2012 at 10:18:20AM -0000, Andy Menzel wrote:
>> Any solution right now? I have a similar problem like Todor Andreev;
>> Our daily backup of some virtual machines (qcow2) looks like that:
>>
>> 1. shutdown the VM
>> 2. create a snapshot via: "qemu-img snapshot -c nameofsnapshot..."
>> 3. boot the VM
>> 4. backup the snapshot to another virtual disk via: "qemu-img convert -f qcow2 -O qcow2 -s nameofsnapshot..."
>> 5. DELETE the snapshot from VM via: qemu-img snapshot -d nameofsnapshot...
>
> It's not safe to modify the qcow2 file while the guest is running. This
> means Step 5 is not really safe and could result in an inconsistent
> image.
>
> This may also be causing the problem: the QEMU process has a variable
> with the next free cluster index. Since Step 5 runs as a separate
> process it does not update the QEMU process' next free cluster index
> variable. QEMU doesn't know that there are now free clusters within the
> image file because you updated the file behind QEMU's back - the result
> is that it grows the file.
>
> Please try deleting the last backup snapshot between Step 1 and Step 2.
> This way you'll free the space while QEMU isn't accessing the image
> file. When you boot up the image file again QEMU should reuse the freed
> clusters.

You might also want to try modifying step 5 to use the HMP delvm monitor
command from within the running qemu rather than going behind qemu's
back with a qemu-img invocation. That's how libvirt deletes internal
snapshots from a running qemu.

Also, there are patches currently under review that are talking about
creating a QMP counterpart to the delvm monitor command.

--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org