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

[Max Reitz]

On 01.10.19 16:53, Vladimir Sementsov-Ogievskiy wrote:
> 01.10.2019 17:34, Max Reitz wrote:
>> On 01.10.19 16:27, Vladimir Sementsov-Ogievskiy wrote:
>>> 01.10.2019 17:13, Max Reitz wrote:
>>>> On 01.10.19 16:00, Vladimir Sementsov-Ogievskiy wrote:
>>>>> 01.10.2019 3:09, John Snow wrote:
>>>>>> Hi folks, I identified a problem with the migration code that Red Hat QE
>>>>>> found and thought you'd like to see it:
>>>>>>
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1652424#c20
>>>>>>
>>>>>> Very, very briefly: drive-mirror inserts a filter node that changes what
>>>>>> bdrv_get_device_or_node_name() returns, which causes a migration problem.
>>>>>>
>>>>>>
>>>>>> Ignorant question #1: Can we multi-parent the filter node and
>>>>>> source-node? It looks like at the moment both consider their only parent
>>>>>> to be the block-job and don't have a link back to their parents 
>>>>>> otherwise.
>>>>>>
>>>>>>
>>>>>> Otherwise: I have a lot of cloudy ideas on how to solve this, but
>>>>>> ultimately what we want is to be able to find the "addressable" name for
>>>>>> the node the bitmap is attached to, which would be the name of the first
>>>>>> ancestor node that isn't a filter. (OR, the name of the block-backend
>>>>>> above that node.)
>>>>>
>>>>> Not the name of ancestor node, it will break mapping: it must be name of 
>>>>> the
>>>>> node itself or name of parent (may be through several filters) 
>>>>> block-backend
>>>>>
>>>>>>
>>>>>> A simple way to do this might be a "child_unfiltered" BdrvChild role
>>>>>> that simply bypasses the filter that was inserted and serves no real
>>>>>> purpose other than to allow the child to have a parent link and find who
>>>>>> it's """real""" parent is.
>>>>>>
>>>>>> Because of flushing, reopen, sync, drain &c &c &c I'm not sure how
>>>>>> feasible this quick idea might be, though.
>>>>>>
>>>>>>
>>>>>> - Corollary fix #1: call error_setg if the bitmap node name that's about
>>>>>> to go over the wire is an autogenerated node: this is never correct!
>>>>>>
>>>>>> (Why not? because the target is incapable of matching the node-name
>>>>>> because they are randomly generated AND you cannot specify node-names
>>>>>> with # prefixes as they are especially reserved!
>>>>>>
>>>>>> (This raises a related problem: if you explicitly add bitmaps to nodes
>>>>>> with autogenerated names, you will be unable to migrate them.))
>>>>>>
>>>>>> --js
>>>>>>
>>>>>
>>>>> What about the following:
>>>>>
>>>>> diff --git a/block.c b/block.c
>>>>> index 5944124845..6739c19be9 100644
>>>>> --- a/block.c
>>>>> +++ b/block.c
>>>>> @@ -1009,8 +1009,20 @@ static void bdrv_inherited_options(int 
>>>>> *child_flags, QDict *child_options,
>>>>>         *child_flags = flags;
>>>>>     }
>>>>>
>>>>> +static const char *bdrv_child_get_name(BdrvChild *child)
>>>>> +{
>>>>> +    BlockDriverState *parent = child->opaque;
>>>>> +
>>>>> +    if (parent->drv && parent->drv->is_filter) {
>>>>> +        return bdrv_get_parent_name(parent);
>>>>> +    }
>>>>> +
>>>>> +    return NULL;
>>>>> +}
>>>>> +
>>>>
>>>> Why would we skip filters explicitly added by the user?
>>>>
>>>
>>> Why not? Otherwise migration of bitmaps will not work: we may have 
>>> different set
>>> of filters on source and destination, and we still should map nodes with 
>>> bitmaps
>>> automatically.
>>
>> Why would we have a different set of explicitly added filters on source
>> and destination and allow them to be automatically changed during
>> migration?  Shouldn’t users only change them pre or post migration?
> 
> Hm I didn't say to automatically change filters.
> 
> I meant, that we must understand the mapping of nodes with bitmaps: if we 
> have source
> node N with bitmaps, in which target node these bitmaps should be after 
> migration?
> And we have to understand it without user interaction.

Well, I’d think it should be on the one with the same node name, but it
appears others don’t want a node-name-based mapping, so maybe I should
just stop trying to be part of the discussion. :-)

> Still, if you don't like skipping explicit filters, I'm OK with implicit 
> only, it will
> fix the bug we are saying about.
> 
> But why you don't like creating some additional explicit filters on target 
> (prior to
> migration process) which we didn't have on source?

Because I feel like (without having too much insight into migration, I
admit) that migration is generally a process where you move from one VM
to another, but both should have the same configuration.  If you want to
change the configuration, you do that before or after the migration.
(I’d think.)

Max

signature.asc
Description: OpenPGP digital signature