All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-block@nongnu.org
Cc: fam@euphon.net, kwolf@redhat.com, vsementsov@virtuozzo.com,
	quintela@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com,
	stefanha@redhat.com, den@openvz.org, mreitz@redhat.com,
	jsnow@redhat.com
Subject: [PATCH v2 4/5] migration/block-dirty-bitmap: fix bitmaps migration during mirror job
Date: Thu, 19 Dec 2019 11:51:05 +0300	[thread overview]
Message-ID: <20191219085106.22309-5-vsementsov@virtuozzo.com> (raw)
In-Reply-To: <20191219085106.22309-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.

Libvirt currently is unprepared to bitmap migration by node-name,
node-names are mostly auto-generated. So actually only migration by blk
name works.

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.

Let's fix it by allowing use blk-name even if some implicit filters are
inserted.

Note, that we possibly want to allow explicit filters skipping too, but
this is another story.

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



  parent reply	other threads:[~2019-12-19  8:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19  8:51 [PATCH v2 0/5] fix migration with bitmaps and mirror Vladimir Sementsov-Ogievskiy
2019-12-19  8:51 ` [PATCH v2 1/5] block: Mark commit and mirror as filter drivers Vladimir Sementsov-Ogievskiy
2020-01-31 19:23   ` Eric Blake
2020-05-14 18:51     ` Eric Blake
2019-12-19  8:51 ` [PATCH v2 2/5] migretion/block-dirty-bitmap: refactor init_dirty_bitmap_migration Vladimir Sementsov-Ogievskiy
2020-01-31 19:28   ` Eric Blake
2019-12-19  8:51 ` [PATCH v2 3/5] block/dirty-bitmap: add bdrv_has_named_bitmaps helper Vladimir Sementsov-Ogievskiy
2020-05-14 18:30   ` Eric Blake
2019-12-19  8:51 ` Vladimir Sementsov-Ogievskiy [this message]
2020-05-14 18:52   ` [PATCH v2 4/5] migration/block-dirty-bitmap: fix bitmaps migration during mirror job Eric Blake
2019-12-19  8:51 ` [PATCH v2 5/5] iotests: 194: test also migration of dirty bitmap Vladimir Sementsov-Ogievskiy
2019-12-19 10:36 ` [PATCH v2 0/5] fix migration with bitmaps and mirror Peter Krempa
2019-12-19 11:39   ` Vladimir Sementsov-Ogievskiy
2020-04-03 11:02   ` Vladimir Sementsov-Ogievskiy
2020-04-03 11:23     ` Peter Krempa
2020-04-03 11:29       ` Vladimir Sementsov-Ogievskiy
2020-04-03 11:52         ` Vladimir Sementsov-Ogievskiy
2020-04-03 15:05           ` Dr. David Alan Gilbert
2020-04-03 15:34             ` Vladimir Sementsov-Ogievskiy
2020-05-14 18:29       ` Eric Blake
2020-05-15  5:52         ` Vladimir Sementsov-Ogievskiy
2020-05-15 11:15           ` Vladimir Sementsov-Ogievskiy
2020-05-15 17:51             ` Eric Blake
2020-05-15 19:49               ` Vladimir Sementsov-Ogievskiy
2020-01-20  9:04 ` Vladimir Sementsov-Ogievskiy

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=20191219085106.22309-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=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.