[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v2] migration: Add migrate-set-bitmap-node-mapping
From: |
Kevin Wolf |
Subject: |
Re: [RFC v2] migration: Add migrate-set-bitmap-node-mapping |
Date: |
Thu, 14 May 2020 13:07:03 +0200 |
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