On Tue, Jun 02, 2020 at 12:56:32 +0200, Max Reitz wrote: > On 18.05.20 18:26, Peter Krempa wrote: > > On Wed, May 13, 2020 at 16:56:10 +0200, 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 <vsement...@virtuozzo.com> > >> Signed-off-by: Max Reitz <mre...@redhat.com> > >> ---
[...] > >> +# @migrate-set-bitmap-node-mapping: > > > > qemu-5.0 deprecated a bunch of migrate-set- specific commands in favor > > of migrate-set-parameters. Is it worth/necessary to add a new command > > here? > > I wasn’t aware of that. It would probably indeed make sense from a > user’s perspective. > > It would make the implementation rather different, though, because > instead of putting the mapping locally (and statically) into > migration/block-dirty-bitmap.c, it would require putting it into the > central MigrationState. Which isn’t to say it’d be worse. I suppose > it’d be better, actually, but I’ll have to try to say for sure. > > You also suggested “setting nothing will clear the mapping” in your > second mail. That would be a weird default. Right now, the default for > all migration parameters is to leave them as-is, so it would be different. > > The first question would be: What do you mean by “clear the mapping”? > Reset it to the original identity mapping? Or actually clear it, so > that no bitmap is migrated? I presume the former, because the latter > can easily be achieved by passing an empty array. Yeah, lucikily this is easy with json: default mapping: "mapping": null empty mapping: "mapping": [ ] > I understand that it seems to make sense to be able to return to the > original identity mapping, but is there actually a use for this? After > you have started using a custom mapping, wouldn’t you always use custom > mappings? Libvirt mostly doesn't care. Downgrade of libvirt version is unsupported so this should not be a problem. > If there is a use for it, I think the better way to do it would be to > use an alternate type where an explicit null resets the mapping to the > identity mapping. yes :)
