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.
