From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, fam@euphon.net, vsementsov@virtuozzo.com,
stefanha@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org,
dgilbert@redhat.com, mreitz@redhat.com, pavel.dovgaluk@ispras.ru,
den@openvz.org, pbonzini@redhat.com, jsnow@redhat.com
Subject: [PATCH v3 4/7] migration/block-dirty-bitmap: fix bitmaps pre-blockdev migration during mirror job
Date: Fri, 15 May 2020 15:40:21 +0300 [thread overview]
Message-ID: <20200515124024.3491-5-vsementsov@virtuozzo.com> (raw)
In-Reply-To: <20200515124024.3491-1-vsementsov@virtuozzo.com>
Important thing for bitmap migration is to select destination block
node to obtain the migrated bitmap.
Prepatch, on source we use bdrv_get_device_or_node_name() to identify
the node, and on target we do bdrv_lookup_bs.
bdrv_get_device_or_node_name() returns blk name only for direct
children of blk. So, bitmaps of direct children of blks are migrated by
blk name and others - by node name.
Old libvirt is unprepared to bitmap migration by node-name,
node-names are mostly auto-generated. So actually only migration by blk
name works for it.
Newer libvirt will use new interface (which will be added soon) to
specify node-mapping for bitmaps migration explicitly. Still, let's
improve the current behavior a bit.
Now, consider classic libvirt migrations assisted by mirror block job:
mirror block job inserts filter, so our source is not a direct child of
blk, and bitmaps are migrated by node-names. And this just don't work
with auto-generated node names
Let's fix it by allowing use blk-name even if some implicit filters are
inserted.
Note2: we, of course, can't skip filters and use blk name to migrate
bitmaps in filtered node by blk name for this blk if these filters have
named bitmaps which should be migrated.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1652424
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
migration/block-dirty-bitmap.c | 39 +++++++++++++++++++++++++++++++++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
index 7e93718086..5d3a7d2b07 100644
--- a/migration/block-dirty-bitmap.c
+++ b/migration/block-dirty-bitmap.c
@@ -319,14 +319,48 @@ static int init_dirty_bitmap_migration(void)
{
BlockDriverState *bs;
DirtyBitmapMigBitmapState *dbms;
+ GHashTable *handled_by_blk = g_hash_table_new(NULL, NULL);
+ BlockBackend *blk;
dirty_bitmap_mig_state.bulk_completed = false;
dirty_bitmap_mig_state.prev_bs = NULL;
dirty_bitmap_mig_state.prev_bitmap = NULL;
dirty_bitmap_mig_state.no_bitmaps = false;
+ /*
+ * Use blockdevice name for direct (or filtered) children of named block
+ * backends.
+ */
+ for (blk = blk_next(NULL); blk; blk = blk_next(blk)) {
+ const char *name = blk_name(blk);
+
+ if (!name || strcmp(name, "") == 0) {
+ continue;
+ }
+
+ bs = blk_bs(blk);
+
+ /* Skip filters without bitmaos */
+ while (bs && bs->drv && bs->drv->is_filter &&
+ !bdrv_has_named_bitmaps(bs))
+ {
+ bs = bs->backing->bs ?: bs->file->bs;
+ }
+
+ if (bs && bs->drv && !bs->drv->is_filter) {
+ if (add_bitmaps_to_list(bs, name)) {
+ goto fail;
+ }
+ g_hash_table_add(handled_by_blk, bs);
+ }
+ }
+
for (bs = bdrv_next_all_states(NULL); bs; bs = bdrv_next_all_states(bs)) {
- if (add_bitmaps_to_list(bs, bdrv_get_device_or_node_name(bs))) {
+ if (g_hash_table_contains(handled_by_blk, bs)) {
+ continue;
+ }
+
+ if (add_bitmaps_to_list(bs, bdrv_get_node_name(bs))) {
goto fail;
}
}
@@ -340,9 +374,12 @@ static int init_dirty_bitmap_migration(void)
dirty_bitmap_mig_state.no_bitmaps = true;
}
+ g_hash_table_destroy(handled_by_blk);
+
return 0;
fail:
+ g_hash_table_destroy(handled_by_blk);
dirty_bitmap_mig_cleanup();
return -1;
--
2.21.0
next prev parent reply other threads:[~2020-05-15 12:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 12:40 [PATCH v3 0/7] fix migration with bitmaps and mirror Vladimir Sementsov-Ogievskiy
2020-05-15 12:40 ` [PATCH v3 1/7] block: Mark commit, mirror, blkreplay as filters Vladimir Sementsov-Ogievskiy
2020-05-15 12:40 ` [PATCH v3 2/7] migration/block-dirty-bitmap: refactor init_dirty_bitmap_migration Vladimir Sementsov-Ogievskiy
2020-05-15 12:40 ` [PATCH v3 3/7] block/dirty-bitmap: add bdrv_has_named_bitmaps helper Vladimir Sementsov-Ogievskiy
2020-05-15 12:40 ` Vladimir Sementsov-Ogievskiy [this message]
2020-05-18 20:36 ` [PATCH v3 4/7] migration/block-dirty-bitmap: fix bitmaps pre-blockdev migration during mirror job Eric Blake
2020-05-19 10:51 ` Vladimir Sementsov-Ogievskiy
2020-05-21 21:01 ` Eric Blake
2020-05-15 12:40 ` [PATCH v3 5/7] iotests: 194: test also migration of dirty bitmap Vladimir Sementsov-Ogievskiy
2020-05-21 21:10 ` Eric Blake
2020-05-15 12:40 ` [PATCH v3 6/7] migration/block-dirty-bitmap: add_bitmaps_to_list: check disk name once Vladimir Sementsov-Ogievskiy
2020-05-21 21:09 ` Eric Blake
2020-05-15 12:40 ` [PATCH v3 7/7] migration/block-dirty-bitmap: forbid migration by generated node-name Vladimir Sementsov-Ogievskiy
2020-05-21 21:05 ` Eric Blake
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=20200515124024.3491-5-vsementsov@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=den@openvz.org \
--cc=dgilbert@redhat.com \
--cc=fam@euphon.net \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pavel.dovgaluk@ispras.ru \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.