Re: [PATCH for-5.2 v3 0/3] migration: Add block-bitmap-mapping parameter

[Vladimir Sementsov-Ogievskiy]

Now this doesn't apply, as code changed a lot after my series
 "[PATCH v4 for-5.1 00/21] Fix error handling during bitmap postcopy"
merged first.

I feel my responsibility for the mess with these series, so if you want I can 
try to rebase and post v4 of this one myself :)

12.08.2020 17:15, Max Reitz wrote:
> Ping – seems like everyone found v2 more or less acceptable bar the
> failing assertion in patch 1, and some aspects of the test.  How about
> v3, are there any objections?
>
> On 22.07.20 10:05, Max Reitz wrote:
> > RFC v1: https://lists.nongnu.org/archive/html/qemu-block/2020-05/msg00912.html
> > RFC v2: https://lists.nongnu.org/archive/html/qemu-block/2020-05/msg00915.html
> > v1: https://lists.nongnu.org/archive/html/qemu-devel/2020-06/msg09792.html
> > v2: https://lists.nongnu.org/archive/html/qemu-block/2020-07/msg01179.html
> >
> > Branch: https://github.com/XanClic/qemu.git migration-bitmap-mapping-v3
> > Branch: https://git.xanclic.moe/XanClic/qemu.git migration-bitmap-mapping-v3
> >
> > Hi,
> >
> > This new migration parameter allows mapping block node names and bitmap
> > names to aliases for the purpose of block dirty bitmap migration.
> >
> > This way, management tools can use different node names on the source
> > and destination and pass the mapping of how bitmaps are to be
> > transferred to qemu (on the source, the destination, or even both with
> > arbitrary aliases in the migration stream).
> >
> >
> > v3:
> > - Patch 1:
> >    - Add notes on the fact that the destination won’t ever know about any
> >      bitmaps that aren’t sent, so you can freely drop what you want, and
> >      you’re completely free in renaming bitmaps and putting them on
> >      “other” nodes (whatever “other” node means in the context of
> >      migration, because that’s kind of one of the problems this series is
> >      trying to solve: The fact that you can’t trivially match nodes
> >      between source and destination)
> >    - Fix an assertion
> >
> > - Patch 2: s/pass/time.sleep(0.2)/
> >
> > - Patch 3:
> >    - Add copyright line
> >    - Use format string instead of %
> >    - s/pass/time.sleep(0.1)/
> >    - s/wait_for_runstate/wait_migration/ on the destination to wait for
> >      the migration to actually complete
> >    - Replace the “info migrate_parameters” parsing code by a multiline
> >      regex
> >    - Test what happens when the destination has a mapping that isn’t used
> >      because there are not bitmaps to be transferred (which breaks the
> >      assertion in patch 1 as it was in v2)
> >    - Let verify_dest_has_all_bitmaps() actually verify the bitmaps on the
> >      destination instead of the source
> >
> >
> > git-backport-diff against v2:
> >
> > Key:
> > [----] : patches are identical
> > [####] : number of functional differences between upstream/downstream patch
> > [down] : patch is downstream-only
> > The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
> >
> > 001/3:[0014] [FC] 'migration: Add block-bitmap-mapping parameter'
> > 002/3:[0003] [FC] 'iotests.py: Add wait_for_runstate()'
> > 003/3:[0046] [FC] 'iotests: Test node/bitmap aliases during migration'
> >
> >
> > Max Reitz (3):
> >    migration: Add block-bitmap-mapping parameter
> >    iotests.py: Add wait_for_runstate()
> >    iotests: Test node/bitmap aliases during migration
> >
> >   qapi/migration.json            | 104 ++++++-
> >   migration/migration.h          |   3 +
> >   migration/block-dirty-bitmap.c | 373 ++++++++++++++++++++----
> >   migration/migration.c          |  30 ++
> >   monitor/hmp-cmds.c             |  30 ++
> >   tests/qemu-iotests/300         | 515 +++++++++++++++++++++++++++++++++
> >   tests/qemu-iotests/300.out     |   5 +
> >   tests/qemu-iotests/group       |   1 +
> >   tests/qemu-iotests/iotests.py  |   5 +
> >   9 files changed, 1011 insertions(+), 55 deletions(-)
> >   create mode 100755 tests/qemu-iotests/300
> >   create mode 100644 tests/qemu-iotests/300.out


--
Best regards,
Vladimir