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-vsement...@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