[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH v2 0/3] migration: Add block-bitmap-mapping parameter
From: |
Max Reitz |
Subject: |
[PATCH v2 0/3] migration: Add block-bitmap-mapping parameter |
Date: |
Thu, 16 Jul 2020 15:53:00 +0200 |
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