Re: bitmap migration bug with -drive while block mirror runs

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

02.10.2019 16:43, Peter Krempa wrote:
> On Wed, Oct 02, 2019 at 13:11:47 +0200, Kevin Wolf wrote:
>> Am 02.10.2019 um 12:46 hat Peter Krempa geschrieben:
> 
> [...]
> 
>>> I'd like to re-iterate that the necessity to keep node names same on
>>> both sides of migration is unexpected, undocumented and in some cases
>>> impossible.
>>
>> I think the (implicitly made) requirement is not that all node-names are
>> kept the same, but only the node-names of those nodes for which
>> migration transfers some state.
> 
> [1] This also implies that node names of the nodes where migration should
> not transfer state must be unique on the both sides since you can't
> control it otherwise.
> 
>> It seems to me that bitmap migration is the first case of putting
>> something in the migration stream that isn't related to a frontend, but
>> to the backend, so the usual device hierarchy to address information
>> doesn't work here. And it seems the implications of this weren't really
>> considered sufficiently, resulting in the design problem we're
>> discussing now.
> 
> This should then also be a moment to carefully think about the
> semantics of migrating data for backends which don't need to be
> identical on both sides of the migration for the VM to work correctly.
> 
> I think that any feature which touches backends should ideally be an
> opt-in. This would call for a explicit action to use it which would also
> allow management apps to consider expectations and implications of
> enabling it rather than doing it automatically. One possibility would be
> also to make it introspectable in such a way that it can be made opt-in
> by disabling all unknown features programatically in the mgmt app.

Currently bitmaps are migrated only if bitmaps migration capability is enabled,
so it's not so bad.

-- 
Best regards,
Vladimir