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
