Re: [Qemu-block] [Qemu-devel] [Questions] Several questions about incremental backup

[John Snow]

On 01/25/2016 02:35 AM, Rudy Zhang wrote:
> I am reading and testing the function: incremental backup in qemu-2.5.
> But I have serveral questions about it.
> 1. If I want to start image backup, at first I need to start full mode backup
>    and then, add a bitmap to trace io, next start incremental backup via the
>    bitmap before we added. But when the first incremental backup over, it will
>    abdicate the bitmap. How can I start the second incremental backup without
>    the bitmap to trace io? I don't know why abdicate the bitmap.
>    Is it only an incremental backup?

Check out https://github.com/qemu/qemu/blob/master/docs/bitmaps.md for
some examples of workflow, hopefully this is useful.

When you create a new bitmap object, it's useful to sync it to a full
backup of some kind so that it's useful, you can do this several ways.
Either QMP commands while the VM is paused, or QMP transactions when the
VM is running. See /docs/bitmaps.md for more information.

When you issue a backup command using an incremental bitmap object, QEMU
actually creates a new bitmap to replace the one you are using right away.

Before a backup: [bitmap0]
During a backup: [bitmap0 <-- "successor"]

The bitmap you create is given an anonymous child bitmap (via the
successor pointer) that records new writes while the backup is in
progress. Two things can happen at this point:

(1) The backup succeeds

The "abdicate" function is run and "bitmap0" is deleted and the
anonymous child becomes the new "bitmap0."

(2) The backup fails

It's not safe to delete bitmap0, so QEMU merges the anonymous child back
into bitmap0.


This means that after the backup you'll always have "bitmap0" attached
to the same drive.

It shouldn't be necessary to manually create new incremental bitmap objects.

> 2. When abdicating the bitmap, it seems leak memory about bitmap->successor.
> 

I guess this function looks very suspicious, but what's happening in
actuality is the successor inherits the name of the parent (e.g.
"bitmap0") and then the parent is freed/deleted.

This "promotes" the successor to the new standalone bitmap object,
because both the parent and the successor are part of the list of
bitmaps attached to the drive object -- we did not lose our reference to
the successor.