qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC v2] migration: Add migrate-set-bitmap-node-mapping


From: Eric Blake
Subject: Re: [RFC v2] migration: Add migrate-set-bitmap-node-mapping
Date: Wed, 13 May 2020 11:11:12 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 5/13/20 9:56 AM, Max Reitz wrote:
This command allows mapping block node 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).

Suggested-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
---

@@ -713,6 +731,44 @@ static bool dirty_bitmap_has_postcopy(void *opaque)
      return true;
  }
+void qmp_migrate_set_bitmap_node_mapping(MigrationBlockNodeMappingList *mapping,
+                                         Error **errp)
+{
+    QDict *in_mapping = qdict_new();
+    QDict *out_mapping = qdict_new();
+
+    for (; mapping; mapping = mapping->next) {
+        MigrationBlockNodeMapping *entry = mapping->value;
+
+        if (qdict_haskey(out_mapping, entry->node_name)) {
+            error_setg(errp, "Cannot map node name '%s' twice",
+                       entry->node_name);
+            goto fail;
+        }

Can we call this command more than once? Is it cumulative (call it once to set mapping for "a", second time to also set mapping for "b"), or should it reset (second call wipes out all mappings from first call, any mappings that must exist must be passed in the final call)?

The idea makes sense, and the interface seems usable. It's nice that either source, destination, or both sides of migration can use it (which helps in upgrade vs. downgrade scenarios).

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




reply via email to

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