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

[Kevin Wolf]

Am 14.05.2020 um 09:13 hat Max Reitz geschrieben:
> 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.

Also, if it were cumulative, we would need a separate reset command
because you probably don't want to use the same mapping you used for an
incoming migration when you later migrate away again to a third host.

Kevin

signature.asc
Description: PGP signature