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

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

15.05.2020 20:51, Eric Blake wrote:
> On 5/15/20 6:15 AM, Vladimir Sementsov-Ogievskiy wrote:
> 
>>>> 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?
>>>>
>>>
>>> My patches are needed to fix migration for the pre-blockdev configuration with mirror-top filter.
>>>
>>> We ofcrouse need them in Virtuozzo, but it's not hard to keep the in downstream-only.. And it will be not simple to use new command from Max in pre-blockdev libvirt configuration, with auto-generated node-names.
> 
> Carrying a downstream fork forever is more work on you.  If the patch is easy enough to maintain, incorporating it upstream is best all around, even if libvirt has moved on to the point of no longer caring since it no longer uses pre-blockdev.

I hope not forever, when Rhel moves to node-names, we will do it too (hmm, I don't know, may be future already came, and Rhel8 libvirt is node-name oriented?) Still, yes it's always better to reduce the downstream overhead

> 
>>>
>>> How much we care about pre-blockdev libvirt now in upstream Qemu?
>>>
>>> If we don't care, than these series are only for downstreams, and we don't need to apply them upstream..
> 
> Eventually, we may want to deprecate pre-blockdev, but I don't think we are there yet, and even when it does happen, it will be two more releases with it being deprecated before it is gone, so we might as well make it work correctly in the meantime.

Agree. Better to fix old behavior first, and then do proper deprecation if needed.

> 
>>>
>>> On the other hand, Max have to resend anyway, to handle old code, which uses device name instead of node-name. And if we don't want to drop now the code which can use device name (needed for old libvirt), why not to apply the series, which just make old code better?
>>>
>>> ====
>>>
>>> In other words: do we still support pre-blockdev libvirt (and any other pre-blockdev users)?
>>>
>>> If we support, than, as I said somewhere, I need to resend these series as I have updated version in our downstream. And I think, I can rebase Max's patch by myself and send together with this all, if no objections.
>>>
>>
>> I'm going to resend the series today, let's look at it.
>>
> 
> Sounds reasonable.
> 

-- 
Best regards,
Vladimir