qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH v2 0/5] fix migration with bitmaps and mirror
Date: Fri, 15 May 2020 22:49:57 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]