[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 0/5] fix migration with bitmaps and mirror
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [PATCH v2 0/5] fix migration with bitmaps and mirror |
Date: |
Fri, 3 Apr 2020 16:05:36 +0100 |
User-agent: |
Mutt/1.13.4 (2020-02-15) |
* Vladimir Sementsov-Ogievskiy (address@hidden) wrote:
> 03.04.2020 14:29, Vladimir Sementsov-Ogievskiy wrote:
> > 03.04.2020 14:23, 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"
> > > > > > <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.
> > >
> >
> > Hmm. Actually, matching by node-name never worked. May be just drop it now,
> > and allow only matching by blk-name?
> >
> > And then (in 5.1) implement special qmp commands for precise mapping.
> >
>
> Hmm, it may break someones setup... Bad idea. Probably we can forbid
> auto-generated node-names.
If we want to remove it I guess we have to go through a proper
deprecation; but that's OK.
The thing to keep in mind is that when people say 'the commandline
should match' on source/destination - that's just not true;
so we have to define what actually needs to stay the same for bitmap
migration to work.
Dave
> --
> Best regards,
> Vladimir
>
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK