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

[Eric Blake]

On 10/4/19 4:24 AM, Vladimir Sementsov-Ogievskiy wrote:

> > The way I see it, we know an auto-generated node name will never be
> > correct, but an explicitly specified one represents an explicit user
> > configuration.
> >
> > It's wrong to use generated names for migration details, but it's never
> > wrong to use explicit configuration.
> >
> > So I believe they are /already/ distinct in nature. We even already have
> > code that can tell them apart.
>
> Is it restricted to create user node-names formatted like automated ones?

Yes. Explicit node names cannot begin with '#', while all generated node 
names do.


> > There are four cases here:
> >
> > - The bitmap is loaded to a root node with an explicit name
> > - The bitmap is loaded to a non-root node with an explicit name
> >
> > The blockdev case with persistence. The name represents explicit user
> > configuration and can be relied upon in the destination.
> >
> > - The bitmap is loaded to a root node with an implicit name, with a named BB
> >
> > The -drive case. The named BB represents the explicit user configuration
> > and can be relied upon.
> >
> > - The bitmap is loaded to a non-root node with an implicit name.
>
> So, do you suggest to save information of haw bitmap was loaded or created in
> BdrvDirtyBitmap structure, to distinguish, how to identify it, by blk name or
> by node-name? And how this information would be updated on bitmap merge? And
> what about creating bitmaps?
>
> So if one bitmap created in node N by blk name B, and another bitmap created in
> same node N by node-name N, will we migrated these bitmaps in different ways?

In the -drive case (historical libvirt), the block device is named, and 
node names are generated (it may be possible to use -drive and still 
create explicit node names, but libvirt will never do that).  You can 
create a bitmap using either ('drive-name','bitmap-name'), or 
('generated-node-name','bitmap-name'), but for the purposes of 
migration, only the 'drive-name' variant is migrateable.

In the -blockdev case (upcoming libvirt), the block device is anonymous, 
and all node names are given by libvirt.  Thus, you can only create a 
bitmap using ('node-name','bitmap-name'), but it is also obvious that 
migration will use the 'node-name' variant.


> > > If it's a problem for libvirt to keep same node-names, why should we insist?
> >
> > Is it really a problem? If libvirt requests migration of bitmaps, those
> > bitmaps need to go somewhere. Even if it constructs a different graph
> > for valid reasons, it should still understand which qcow2 nodes
> > correlate to which other qcow2 nodes and name them accordingly.
> >
> > I don't see why this is actually a terrible constraint. Even in our
> > mapping proposal we're still using node-names.

The obvious case I see is that if we have a source:

Backing.qcow2 (contains bitmap1) <- Active.qcow2 (contains bitmap2)

and we want to migrate AND flatten at the same time, but still preserve 
the bitmaps as a record of changes between the points in time, then 
libvirt needs a way to specify migration to:

Flattened.qcow2 (contains bitmap1 and bitmap2)

No matter which node name libvirt assigns to Flattened.qcow2, at least 
one of the two bitmaps on the source will be migrated to a different 
node name on the destination, while still giving the net result of a 
bitmap logically associated with the drive (and not any particular node).


> Ok, I'm not completely against node-name matching, keeping in mind that it is
> current default behavior anyway. And I see Peter not completely against too.
>
> But I'd prefer to select default name from current moment, not involving 
> information
> of "how bitmap was created or loaded", as it may lead to migrating bitmaps from 
> one
> node in different ways which seems inconsistent.

As long as a bitmap never has both names non-generated, we should be 
fine (it either has an explicit drive name and generated node name, or 
it has no drive name and an explicit node name).

> Current default is blk name. And node-name if blk name is not available. So I 
> think
> the only thing to fix right now is skipping filters. We possibly may 
> additionally
> restrict migrating bitmaps without blk name and with generated node-name.

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