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

[Peter Krempa]

On Tue, Oct 01, 2019 at 08:57:37 +0000, 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.)
> 
> 
> 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?

They may be different. Some time ago when I asked I was told that node
names are not bound to any state in qemu and thus can be re-created on
destination. Otherwise they technically become guest ABI which would
require changes to libvirt's blockdev usage.