qemu-devel
[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: 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




reply via email to

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