[Qemu-devel] [Questions] Several questions about incremental backup

[Qemu-devel] [Questions] Several questions about incremental backup

[Rudy Zhang]

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?
2. When abdicating the bitmap, it seems leak memory about bitmap->successor.

Re: [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.

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

[Rudy Zhang]

On 16/1/26 上午3:19, John Snow wrote:
> 
> 
> 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.
> 

I carefully read the code again, and understand the implementation.
Thank you very much.