[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v2] migration: Add migrate-set-bitmap-node-mapping
From: |
Max Reitz |
Subject: |
Re: [RFC v2] migration: Add migrate-set-bitmap-node-mapping |
Date: |
Thu, 14 May 2020 09:13:48 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 13.05.20 18:11, Eric Blake wrote:
> 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)?
I tried to make it clear in the documentation:
> +# @mapping: The mapping; must be one-to-one, but not necessarily
> +# complete. Any mapping not given will be reset to the
> +# default (i.e. the identity mapping).
So everything that isn’t set in the second call is reset. I thought
about what you proposed (because I guess that’s the most intuitive
idea), but after consideration I didn’t see why we’d need different
behavior, so it would only serve to make the code more complicated.
Max
> 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).
signature.asc
Description: OpenPGP digital signature