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

[John Snow]

On 10/4/19 9:07 AM, Eric Blake wrote:
> On 10/4/19 4:24 AM, Vladimir Sementsov-Ogievskiy wrote:
> 
>>> The way I see it, we know an auto-generated node name will never be
>>> correct, but an explicitly specified one represents an explicit user
>>> configuration.
>>>
>>> It's wrong to use generated names for migration details, but it's never
>>> wrong to use explicit configuration.
>>>
>>> So I believe they are /already/ distinct in nature. We even already have
>>> code that can tell them apart.
>>
>> Is it restricted to create user node-names formatted like automated ones?
> 
> Yes. Explicit node names cannot begin with '#', while all generated node
> names do.

Right, we already have id_wellformed which tells us which kind of node
names are which. Automatic ones are not wellformed, explicit ones are.

Peter's latest reply to my wall of text is cooling me off on the plan I
laid out in that missive, though.

> 
> 
>>> There are four cases here:
>>>
>>> - The bitmap is loaded to a root node with an explicit name
>>> - The bitmap is loaded to a non-root node with an explicit name
>>>
>>> The blockdev case with persistence. The name represents explicit user
>>> configuration and can be relied upon in the destination.
>>>
>>> - The bitmap is loaded to a root node with an implicit name, with a
>>> named BB
>>>
>>> The -drive case. The named BB represents the explicit user configuration
>>> and can be relied upon.
>>>
>>> - The bitmap is loaded to a non-root node with an implicit name.
>>
>> So, do you suggest to save information of haw bitmap was loaded or
>> created in
>> BdrvDirtyBitmap structure, to distinguish, how to identify it, by blk
>> name or
>> by node-name? And how this information would be updated on bitmap
>> merge? And
>> what about creating bitmaps?
>>
>> So if one bitmap created in node N by blk name B, and another bitmap
>> created in
>> same node N by node-name N, will we migrated these bitmaps in
>> different ways?
> 
> In the -drive case (historical libvirt), the block device is named, and
> node names are generated (it may be possible to use -drive and still
> create explicit node names, but libvirt will never do that).  You can
> create a bitmap using either ('drive-name','bitmap-name'), or
> ('generated-node-name','bitmap-name'), but for the purposes of
> migration, only the 'drive-name' variant is migrateable.
> 
> In the -blockdev case (upcoming libvirt), the block device is anonymous,
> and all node names are given by libvirt.  Thus, you can only create a
> bitmap using ('node-name','bitmap-name'), but it is also obvious that
> migration will use the 'node-name' variant.
> 
> 
>>>>
>>>> If it's a problem for libvirt to keep same node-names, why should we
>>>> insist?
>>>>
>>>>
>>>
>>> Is it really a problem? If libvirt requests migration of bitmaps, those
>>> bitmaps need to go somewhere. Even if it constructs a different graph
>>> for valid reasons, it should still understand which qcow2 nodes
>>> correlate to which other qcow2 nodes and name them accordingly.
>>>
>>> I don't see why this is actually a terrible constraint. Even in our
>>> mapping proposal we're still using node-names.
>>>
>>>
> 
> The obvious case I see is that if we have a source:
> 
> Backing.qcow2 (contains bitmap1) <- Active.qcow2 (contains bitmap2)
> 
> and we want to migrate AND flatten at the same time, but still preserve
> the bitmaps as a record of changes between the points in time, then
> libvirt needs a way to specify migration to:
> 
> Flattened.qcow2 (contains bitmap1 and bitmap2)
> 
> No matter which node name libvirt assigns to Flattened.qcow2, at least
> one of the two bitmaps on the source will be migrated to a different
> node name on the destination, while still giving the net result of a
> bitmap logically associated with the drive (and not any particular node).
> 

A good example that clearly demonstrates the need for an explicit
mapping provided by libvirt.

> 
>> Ok, I'm not completely against node-name matching, keeping in mind
>> that it is
>> current default behavior anyway. And I see Peter not completely
>> against too.
>>
>> But I'd prefer to select default name from current moment, not
>> involving information
>> of "how bitmap was created or loaded", as it may lead to migrating
>> bitmaps from one
>> node in different ways which seems inconsistent.
> 
> As long as a bitmap never has both names non-generated, we should be
> fine (it either has an explicit drive name and generated node name, or
> it has no drive name and an explicit node name).
> 
>>
>> Current default is blk name. And node-name if blk name is not
>> available. So I think
>> the only thing to fix right now is skipping filters. We possibly may
>> additionally
>> restrict migrating bitmaps without blk name and with generated node-name.
>>
>