From: Max Reitz <mreitz@redhat.com>
To: qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
Juan Quintela <quintela@redhat.com>, John Snow <jsnow@redhat.com>,
qemu-devel@nongnu.org,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
Peter Krempa <pkrempa@redhat.com>, Max Reitz <mreitz@redhat.com>
Subject: [PATCH v4 0/4] migration: Add block-bitmap-mapping parameter
Date: Tue, 18 Aug 2020 15:32:36 +0200 [thread overview]
Message-ID: <20200818133240.195840-1-mreitz@redhat.com> (raw)
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
v3: https://lists.nongnu.org/archive/html/qemu-block/2020-07/msg01385.html
Branch: https://github.com/XanClic/qemu.git migration-bitmap-mapping-v4
Branch: https://git.xanclic.moe/XanClic/qemu.git migration-bitmap-mapping-v4
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).
v4:
- Patch 1:
- Rebased
- %s/5.1/5.2/
- The destination side will now ignore unmapped aliases, too (though
they are reported to stderr)
- Check that the aliases given will fit in the migration stream (i.e.
are shorter than 256 bytes)
- On that note, fix a pre-existing bug where a bitmap with a name
longer than 255 bytes would make qemu_put_counted_string() fail an
assertion
- Patch 2:
- import time (apparently, I forgot that in v3...?)
- Patch 3:
- Added; I need this now
- Patch 4:
- Migration rarely ever really fails now (just one case, where a
non-aliased bitmap name is too long, which can only be detected when
beginning migration)
- Thus, we have to read most error messages from the VM log now, for
which I’ve added a new function (verify_dest_error)
- Added tests for overly long bitmap names and node/bitmap aliases
git-backport-diff against v3:
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/4:[0167] [FC] 'migration: Add block-bitmap-mapping parameter'
002/4:[0001] [FC] 'iotests.py: Add wait_for_runstate()'
003/4:[down] 'iotests.py: Let wait_migration() return on failure'
004/4:[0232] [FC] 'iotests: Test node/bitmap aliases during migration'
Max Reitz (4):
migration: Add block-bitmap-mapping parameter
iotests.py: Add wait_for_runstate()
iotests.py: Let wait_migration() return on failure
iotests: Test node/bitmap aliases during migration
qapi/migration.json | 101 +++++-
migration/migration.h | 3 +
migration/block-dirty-bitmap.c | 409 +++++++++++++++++++---
migration/migration.c | 30 ++
monitor/hmp-cmds.c | 30 ++
tests/qemu-iotests/300 | 595 +++++++++++++++++++++++++++++++++
tests/qemu-iotests/300.out | 5 +
tests/qemu-iotests/group | 1 +
tests/qemu-iotests/iotests.py | 22 +-
9 files changed, 1134 insertions(+), 62 deletions(-)
create mode 100755 tests/qemu-iotests/300
create mode 100644 tests/qemu-iotests/300.out
--
2.26.2
next reply other threads:[~2020-08-18 13:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-18 13:32 Max Reitz [this message]
2020-08-18 13:32 ` [PATCH v4 1/4] migration: Add block-bitmap-mapping parameter Max Reitz
2020-08-20 1:17 ` Eric Blake
2020-08-20 12:57 ` Max Reitz
2020-08-20 12:58 ` Vladimir Sementsov-Ogievskiy
2020-08-20 13:32 ` Max Reitz
2020-08-18 13:32 ` [PATCH v4 2/4] iotests.py: Add wait_for_runstate() Max Reitz
2020-08-20 1:19 ` Eric Blake
2020-08-20 14:23 ` Dr. David Alan Gilbert
2020-08-20 14:34 ` Vladimir Sementsov-Ogievskiy
2020-08-20 14:56 ` Max Reitz
2020-08-20 13:36 ` Vladimir Sementsov-Ogievskiy
2020-08-18 13:32 ` [PATCH v4 3/4] iotests.py: Let wait_migration() return on failure Max Reitz
2020-08-20 1:21 ` Eric Blake
2020-08-20 13:42 ` Vladimir Sementsov-Ogievskiy
2020-08-18 13:32 ` [PATCH v4 4/4] iotests: Test node/bitmap aliases during migration Max Reitz
2020-08-20 1:58 ` Eric Blake
2020-08-20 13:17 ` Max Reitz
2020-08-20 13:52 ` Vladimir Sementsov-Ogievskiy
2020-08-20 15:49 ` Vladimir Sementsov-Ogievskiy
2020-08-21 0:44 ` Eric Blake
2020-08-21 11:36 ` Vladimir Sementsov-Ogievskiy
2020-08-21 8:09 ` Max Reitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200818133240.195840-1-mreitz@redhat.com \
--to=mreitz@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=pkrempa@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).