* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) 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" > > > > > > <315cff78-dcdb-a3ce-2742-da3cc9f0c...@redhat.com> > > > > > > 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 / dgilb...@redhat.com / Manchester, UK