Re: [Qemu-devel] [PATCH 0/8] block: persistent dirty bitmaps (RFC)

[Vladimir Sementsov-Ogievskiy <vsementsov@parallels.com>]

On 04.02.2015 18:20, John Snow wrote:
>
>
> On 02/04/2015 10:07 AM, Vladimir Sementsov-Ogievskiy wrote:
>> On 13.01.2015 20:02, Vladimir Sementsov-Ogievskiy wrote:
>>> The bitmaps are saved into qcow2 file format. It provides both
>>> 'internal' and 'external' dirty bitmaps feature:
>>>   - for qcow2 drives we can store bitmaps in the same file
>>>   - for other formats we can store bitmaps in the separate qcow2 file
>>>
>>> QCow2 header is extended by fields 'nb_dirty_bitmaps' and
>>> 'dirty_bitmaps_offset' like with snapshots.
>>>
>>> Proposed command line syntax is the following:
>>>
>>> -dirty-bitmap [option1=val1][,option2=val2]...
>>>      Available options are:
>>>      name         The name for the bitmap (necessary).
>>>
>>>      file         The file to load the bitmap from.
>>>
>>>      file_id      When specified with 'file' option, then this file 
>>> will
>>>                   be available through this id for other -dirty-bitmap
>>>                   options when specified without 'file' option, then it
>>>                   is a reference to 'file', specified with another
>>>                   -dirty-bitmap option, and it will be used to load the
>>>                   bitmap from.
>>>
>>>      drive        The drive to bind the bitmap to. It should be 
>>> specified
>>>                   as 'id' suboption of one of -drive options. If nor
>>>                   'file' neither 'file_id' are specified, then the 
>>> bitmap
>>>                   will be loaded from that drive (internal dirty 
>>> bitmap).
>>>
>>>      granularity  The granularity for the bitmap. Not necessary, the
>>>                   default value may be used.
>>>
>>>      enabled      on|off. Default is 'on'. Disabled bitmaps are not
>>>                   changing regardless of writes to corresponding drive.
>>>
>>> Examples:
>>>
>>> qemu -drive file=a.qcow2,id=disk -dirty-bitmap name=b,drive=disk
>>> qemu -drive file=a.raw,id=disk \
>>>       -dirty-bitmap name=b,drive=disk,file=b.qcow2,enabled=off
>>>
>>> Vladimir Sementsov-Ogievskiy (8):
>>>    spec: add qcow2-dirty-bitmaps specification
>>>    hbitmap: store / restore
>>>    qcow2: add dirty-bitmaps feature
>>>    block: store persistent dirty bitmaps
>>>    block: add bdrv_load_dirty_bitmap
>>>    qemu: command line option for dirty bitmaps
>>>    qmp: print dirty bitmap
>>>    iotests: test internal persistent dirty bitmap
>>>
>>>   block.c                    | 113 ++++++++++
>>>   block/Makefile.objs        |   2 +-
>>>   block/qcow2-dirty-bitmap.c | 514
>>> +++++++++++++++++++++++++++++++++++++++++++++
>>>   block/qcow2.c              |  26 +++
>>>   block/qcow2.h              |  48 +++++
>>>   blockdev.c                 |  51 +++++
>>>   docs/specs/qcow2.txt       |  59 ++++++
>>>   hmp-commands.hx            |  15 ++
>>>   hmp.c                      |   8 +
>>>   hmp.h                      |   1 +
>>>   include/block/block.h      |   9 +
>>>   include/block/block_int.h  |  10 +
>>>   include/qemu/hbitmap.h     |  49 +++++
>>>   include/sysemu/blockdev.h  |   1 +
>>>   include/sysemu/sysemu.h    |   1 +
>>>   qapi-schema.json           |   3 +-
>>>   qapi/block-core.json       |   3 +
>>>   qemu-options.hx            |  37 ++++
>>>   qmp-commands.hx            |   5 +
>>>   tests/qemu-iotests/115     |  96 +++++++++
>>>   tests/qemu-iotests/115.out |  64 ++++++
>>>   tests/qemu-iotests/group   |   1 +
>>>   util/hbitmap.c             |  87 ++++++++
>>>   vl.c                       | 100 +++++++++
>>>   24 files changed, 1301 insertions(+), 2 deletions(-)
>>>   create mode 100644 block/qcow2-dirty-bitmap.c
>>>   create mode 100755 tests/qemu-iotests/115
>>>   create mode 100644 tests/qemu-iotests/115.out
>>>
>>
>> Ping. I've already done (locally):
>> 1) using qcow2 header extension instead of changing the header
>> 2) normal qmp query request instead of "print dirty bitmap"
>>   - thanks to Eric and Markus
>>
>> Now I'm waiting for some comments on the concept and it's realization to
>> roll v3.
>>
>
> My apologies, I've been sick for a while. I'll get going on finishing 
> review of these two series.
>
> I assume you'd like to merge the bitmaps migration first?
>
> --js

The sequence is not important. These series are necessary for making a 
complete backup solution - don't lose named dirty bitmaps on shutdown 
and migration. Shutdown is more often task, and dirty bitmaps migration 
was appeared as a subtask when we were discussed the format for saving 
dirty bitmaps. But they both are needed, then, ok, let's start with 
migration.

-- 
Best regards,
Vladimir