[PATCH v2 0/3] migration: Add block-bitmap-mapping parameter

[Max Reitz]

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

Branch: https://github.com/XanClic/qemu.git migration-bitmap-mapping-v2
Branch: https://git.xanclic.moe/XanClic/qemu.git migration-bitmap-mapping-v2

Based-on: <20200626130658.76498-1-vsementsov@virtuozzo.com>
          (“migration/block-dirty-bitmap: fix add_bitmaps_to_list”)


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).


v2:
- Dropped what used to be patch 1 (the memleak fix), I see the exact
  same fix has been sent concurrently and has been merged as
  9728ebfb77f0159f4

- Patch 1:
  - Changed documentation to clarify the default behavior
  - s/5.1/5.2/
  - Dropped dead assignment
  - Fixed bitmaps_map memleak
  - Assert that the bs_name given to add_bitmaps_to_list() must be the
    BDS’s node name if an alias_map is given
  - On the source side, unmapped bitmaps are simply dropped without
    error
  - On the destination side, unmapped aliases still result in errors
    (see patch 1 for a short explanation on my reasoning)
  - Fixed a bug in qmp_query_migrate_parameters(): We have to clone
    s->parameters.block_bitmap_mapping, not
    params->block_bitmap_mapping, or the latter will just stay NULL (and
    so qmp_query_migrate_parameters() won’t return a result for the
    block-bitmap-mapping)
  - Emit the mapping through HMP’s “info migrate_parameters”
  - Return an error when trying to set the mapping through HMP (instead
    of just crashing because of an “assert(0)” signalling an unhandled
    migration parameter)

- Patch 3:
  - Type alias for BlockBitmapMapping
  - Check the result of “info migrate_parameters” whenever setting the
    block-bitmap-mapping (just to test the new formatting code)
  - Catch the qemu.machine.AbnormalShutdown exception on the destination
    VM whenever the migration is expected to fail
    (necessary since commit ef5d474472426eda6abf81)
  - Cases where we don’t set up a mapping for some bitmap on the source
    are now expected to succeed (without the bitmap being migrated)


git-backport-diff against v1:

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:[0117] [FC] 'migration: Add block-bitmap-mapping parameter'
002/3:[----] [--] 'iotests.py: Add wait_for_runstate()'
003/3:[0202] [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            |  92 +++++-
 migration/migration.h          |   3 +
 migration/block-dirty-bitmap.c | 373 ++++++++++++++++++++----
 migration/migration.c          |  30 ++
 monitor/hmp-cmds.c             |  30 ++
 tests/qemu-iotests/300         | 511 +++++++++++++++++++++++++++++++++
 tests/qemu-iotests/300.out     |   5 +
 tests/qemu-iotests/group       |   1 +
 tests/qemu-iotests/iotests.py  |   4 +
 9 files changed, 994 insertions(+), 55 deletions(-)
 create mode 100755 tests/qemu-iotests/300
 create mode 100644 tests/qemu-iotests/300.out

-- 
2.26.2