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

[Eric Blake]

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.

> > 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.

> > 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.

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