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.
