Re: bitmap migration bug with -drive while block mirror runs

[Kevin Wolf]

Am 01.10.2019 um 18:12 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 01.10.2019 18:58, Kevin Wolf wrote:
> > Am 01.10.2019 um 17:09 hat John Snow geschrieben:
> >>
> >>
> >> On 10/1/19 5:54 AM, Kevin Wolf wrote:
> >>> Am 01.10.2019 um 10:57 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >>>> 01.10.2019 3:09, John Snow wrote:
> >>>>> Hi folks, I identified a problem with the migration code that Red Hat QE
> >>>>> found and thought you'd like to see it:
> >>>>>
> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1652424#c20
> >>>>>
> >>>>> Very, very briefly: drive-mirror inserts a filter node that changes what
> >>>>> bdrv_get_device_or_node_name() returns, which causes a migration 
> >>>>> problem.
> >>>>>
> >>>>>
> >>>>> Ignorant question #1: Can we multi-parent the filter node and
> >>>>> source-node? It looks like at the moment both consider their only parent
> >>>>> to be the block-job and don't have a link back to their parents 
> >>>>> otherwise.
> >>>>>
> >>>>>
> >>>>> Otherwise: I have a lot of cloudy ideas on how to solve this, but
> >>>>> ultimately what we want is to be able to find the "addressable" name for
> >>>>> the node the bitmap is attached to, which would be the name of the first
> >>>>> ancestor node that isn't a filter. (OR, the name of the block-backend
> >>>>> above that node.)
> >>>>
> >>>>
> >>>> Better would be to migrate by node-name only.. But am I right that
> >>>> node-names are different on source and destination? Or this situation
> >>>> changed?
> >>>
> >>> Traditionally, I think migration assumes that frontends (guest devices)
> >>> must match exactly, but backends may and usually will differ.
> >>>
> >>> Of course, dirty bitmaps are a backend feature that isn't really related
> >>> to guest devices, so this doesn't really work out any more in your case.
> >>> BlockBackend names are unusable for this purpose (especially as we're
> >>> moving towards anonymous BlockBackends everywhere), which I guess
> >>> essentially means node-name is the only option left.
> >>>
> >>
> >> The problem as I see it involves API stability.
> >>
> >> We allow block-dirty-bitmap-add against e.g. "drive1" through the
> >> block-backend name (the name of the "drive" as the user sees it.)
> >>
> >> Of course, once you start mirror, you aren't able to access that bitmap
> >> through that namepair anymore -- the "address" of the bitmap has "changed"!
> >>
> >> (In actual fact, the bitmap always had two addresses; and simply we lost
> >> an alias -- but it's the one that the user likely used to create the
> >> bitmap, so that's bad.)
> > 
> > So if I understand correctly, the problem is that without a filter, in
> > some setups we get a usable BlockBackend name like "drive1", but when a
> > filter is added, we return the node-name instead which is
> > auto-generated and will be different on the destination.
> > 
> > Looking at the ChildRole documentation:
> > 
> >      /* Returns a name that is supposedly more useful for human users than 
> > the
> >       * node name for identifying the node in question (in particular, a BB
> >       * name), or NULL if the parent can't provide a better name. */
> >      const char *(*get_name)(BdrvChild *child);
> > 
> > I'd argue that a BlockBackend name is more useful for a human user even
> > across filter, so I'd support a .get_name implementation for a filter
> > child role (which Max wanted to introduce anyway for his filter series).
> > 
> > Of course, if you have a function that is made to return a convenient
> > text for human users, and you use it for a stable ABI like the migration
> > stream, this is an idea that would certainly have caused an entertaining
> > Linus rant in the good old kernel times.
> > 
> >>> Is bitmap migration something that must be enabled explicitly or does
> >>> it happen automatically? If it's explicit, then making an additional
> >>> requirement (matching node-names) shouldn't be a problem.
> >>
> >> This means that bitmap migration becomes a blockdev-only feature.
> > 
> > I meant this more as the preferred way for the future rather than the
> > only thing supported.
> > 
> > But Peter has actually mentioned that for libvirt it will be
> > blockdev-only anyway. So do we even have a good reason to invest much
> > for the non-blockdev case?
> > 
> > Maybe making it blockdev-only is actually pretty reasonable.
> 
> We in Virtuozzo use bitmap migration, so I'd have to fix it at least
> downstream (it seems easier than switch downstream libvirt to blockdev now).
> 
> And what about original bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1652424#c20
> ?
> 
> Also, if we make it blockdev-only upstream, what we mean by that? Node names
> on destination must match, or we add additional qmp command
> migration-set-bitmap-node-mapping, to specify mapping between node names on
> source and target?

Good question. :-)

I would have thought that just having matching node-names would be
pretty convenient for users, but Peter seems to disagree.

With a separate migration-set-bitmap-node-mapping, what would we do if
migrate is called before a mapping is configured? Would this cause
migration failure? I would find that pretty heavy.

Maybe default to a 1:1 mapping and allow the user to override it? (And
if so, do we do the mapping on the source or the destination?)

Kevin