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

[Peter Krempa]

On Tue, Oct 01, 2019 at 12:07:54 -0400, John Snow wrote:
> 
> 
> On 10/1/19 11:57 AM, Vladimir Sementsov-Ogievskiy wrote:
> > 01.10.2019 17:10, John Snow wrote:
> >>
> >>
> >> 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:
> >>
> 
> Amendment:
>    - If our local node-name N is well-formed, use this.

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.

If you want to mandate that they must be kept the same please document
it and also note the following:

- during migrations the storage layout may change e.g. a backing chain
  may become flattened, thus keeping node names stable beyond the top
  layer is impossible

- in some cases (readonly image in a cdrom not present on destination,
  thus not relevant here probably) it may even become impossible to
  create any node thus keeping the top node may be impossible

- it should be documented when and why this happens and how management
  tools are supposed to do it

- please let me know what's actually expected, since libvirt
  didn't enable blockdev yet we can fix any unexpected expectations

- Document it so that the expectations don't change after this.

- Ideally node names will not be bound to anything and freely
  changeable. If necessary we can provide a map to qemu during migration
  which is probably less painful and more straightforward than keeping
  them in sync somehow ...

>    - Otherwise:
> >> - Find the first non-filter ancestor, A
> >> - if A is not a block-backend, we must use our node-local name.
>      Amendment: If it's not a BB, we have no addressable name
>                 for the bitmap and this is an error.
> >> - if A's name is empty, we must use our node-local name.
>      Amendment: If it's empty, we have no addressable name
>                 for the bitmap and this is an error.
> >> - 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!
>      (Handled by above amendments.)