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

[Eric Blake <eblake@redhat.com>]

reviving this thread...

On 4/3/20 6:23 AM, Peter Krempa wrote:
> 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"
>>>> <315cff78-dcdb-a3ce-2742-da3cc9f0ca97@redhat.com>
>>>> 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.

Max is trying to tackle the node-name issue:
https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg03358.html

And trying to apply that patch after staging this series hits a conflict 
in mnigration/block-dirty-bitmap.c.  Which one should go in first?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org