Re: [PATCH v2 0/5] fix migration with bitmaps and mirror

[Peter Krempa]

On Fri, Apr 03, 2020 at 14:02:47 +0300, Vladimir Sementsov-Ogievskiy wrote:
> 19.12.2019 13:36, Peter Krempa wrote:
> > On Thu, Dec 19, 2019 at 11:51:01 +0300, Vladimir Sementsov-Ogievskiy wrote:
> > > Hi all!
> > > 
> > > It's a continuation for
> > > "bitmap migration bug with -drive while block mirror runs"
> > > <address@hidden>
> > > https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg07241.html
> > > 
> > > The problem is that bitmaps migrated to node with same node-name or
> > > blk-parent name. And currently only the latter actually work in libvirt.
> > > And with mirror-top filter it doesn't work, because
> > > bdrv_get_device_or_node_name don't go through filters.
> > 
> > I want to point out that since libvirt-5.10 we use -blockdev to
> > configure the backend of storage devices with qemu-4.2 and later. This
> > means unfortunately that the BlockBackend of the drive does not have a
> > name any more and thus the above will not work even if you make the
> > lookup code to see through filters.
> 
> Not that this series doesn't make things worse, as it loops through named
> block backends when trying to use their name for migration. So with these
> patches applied, qemu will just work in more possible scenarios.

Okay, if that's so it's fair enough in this case.

I'm just very firmly against baking in the assumption that
node names mean the same thing accross migration, because that will
create a precedent situation and more stuff may be baked in on top of
this in the future. It seems that it has already happened though and
it's wrong. And the worst part is that it's never mentioned that this
might occur. But again, don't do that and preferrably remove the
matching of node names for bitmaps altogether until we can control it
arbitrarily.

We've also seen this already before with the backend name of memory
devices being baked in to the migration stream which creates an unwanted
dependancy.