[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/4] migration: Add block-bitmap-mapping parameter

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH 2/4] migration: Add block-bitmap-mapping parameter
Date: Thu, 2 Jul 2020 13:40:32 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

02.07.2020 12:41, Max Reitz wrote:
On 02.07.20 11:19, Vladimir Sementsov-Ogievskiy wrote:
02.07.2020 11:09, Max Reitz wrote:
On 01.07.20 16:34, Vladimir Sementsov-Ogievskiy wrote:
30.06.2020 11:45, Max Reitz wrote:
This 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 and bitmap 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).

Suggested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
    qapi/migration.json            |  83 +++++++-
    migration/migration.h          |   3 +
    migration/block-dirty-bitmap.c | 372
    migration/migration.c          |  29 +++
    4 files changed, 432 insertions(+), 55 deletions(-)

diff --git a/qapi/migration.json b/qapi/migration.json
index d5000558c6..5aeae9bea8 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -507,6 +507,44 @@
      'data': [ 'none', 'zlib',
                { 'name': 'zstd', 'if': 'defined(CONFIG_ZSTD)' } ] }
+# @BitmapMigrationBitmapAlias:
+# @name: The name of the bitmap.
+# @alias: An alias name for migration (for example the bitmap name on
+#         the opposite site).
+# Since: 5.1
+{ 'struct': 'BitmapMigrationBitmapAlias',
+  'data': {
+      'name': 'str',
+      'alias': 'str'
+  } }
+# @BitmapMigrationNodeAlias:
+# Maps a block node name and the bitmaps it has to aliases for dirty
+# bitmap migration.
+# @node-name: A block node name.
+# @alias: An alias block node name for migration (for example the
+#         node name on the opposite site).
+# @bitmaps: Mappings for the bitmaps on this node.
+# Since: 5.1
+{ 'struct': 'BitmapMigrationNodeAlias',
+  'data': {
+      'node-name': 'str',
+      'alias': 'str',
+      'bitmaps': [ 'BitmapMigrationBitmapAlias' ]

So, we still can't migrate bitmaps from one node to different nodes,
but we
also don't know a usecase for it, so it seems OK. But with such
scheme we
can select and rename bitmaps in-flight, and Peter said about

I'm OK with this, still, just an idea in my mind:

we could instead just have a list of

BitmapMigrationAlias: {

so, mapping is set for each bitmap in separate.

Well, OK, but why?

But why not :) Just thinking out loud. May be someone will imaging good
reasons for it.

The reason for “Why not” is that this code now exists. ;)

Exactly :) But another arguments may appear, who knows. If not - great.

Actual reason is more flexible interface: you can migrate any bitmap to any 
node with any name (except for conflicts of course). But do we need it, I don't 
know. I'd like to hear Peter's opinion, if he don't have preference, then I 
don't care too.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]