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

[Peter Krempa]

On Tue, Oct 01, 2019 at 11:54:16 +0200, Kevin Wolf wrote:
> Am 01.10.2019 um 10:57 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > 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.)
> > 
> > 
> > Better would be to migrate by node-name only.. But am I right that
> > node-names are different on source and destination? Or this situation
> > changed?
> 
> Traditionally, I think migration assumes that frontends (guest devices)
> must match exactly, but backends may and usually will differ.
> 
> Of course, dirty bitmaps are a backend feature that isn't really related
> to guest devices, so this doesn't really work out any more in your case.
> BlockBackend names are unusable for this purpose (especially as we're
> moving towards anonymous BlockBackends everywhere), which I guess
> essentially means node-name is the only option left.
> 
> Is bitmap migration something that must be enabled explicitly or does
> it happen automatically? If it's explicit, then making an additional
> requirement (matching node-names) shouldn't be a problem.

I think a far better and more reasonable solution is to provide a map on
migration which would match the node names explicitly. If they have to
be the same it moves node names together with the frontend options as
guest ABI.

This means that changing the disk backend on migration will become very
painful.