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

[John Snow <jsnow@redhat.com>]

On 10/1/19 10:00 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 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
> 

Ah, you are right of course -- because block-backends are the only
"nodes" for which we actually descend the graph and add the bitmap to
its child.

So the real back-resolution mechanism is:

- Find the first non-filter ancestor, A
- if A is not a block-backend, we must use our node-local name.
- if A's name is empty, we must use our node-local name.
- If the name we have chosen is not id_wellformed, we have no
migration-stable addressable name for this bitmap and the migration must
fail!


For resolving bitmap addresses via QMP (node, name) pairs; the
resolution method would be this:

- if the node-name N is a block-backend, descend the tree until we find
the first non-filter node V.
- if the node-name N is a BlockDriverState, use this node directly.


(I don't have the time to investigate the code snippet right now; my
attention is being pulled to a different project. sorry!)