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

[Peter Krempa]

On Thu, Oct 03, 2019 at 19:34:56 -0400, John Snow wrote:
> On 10/3/19 6:14 AM, Vladimir Sementsov-Ogievskiy wrote:
> > 03.10.2019 0:35, John Snow wrote:
> >> On 10/2/19 6:46 AM, Peter Krempa wrote:
> > ====

[...]

(I'm sorry if I ignored something which might require input in the
trimmed part but I don't have enough mental capacity to follow this
thread fully)

> > 
> > 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.

Well, no it is not a problem. Since bitmap migration has a migration
capability and libvirt by default disables all unknown migration
capabilities we can deal with it.

We have measures to transfer state to the destination we can
basically do the equivalent of the explicit mapping but with extra
steps.

We know where we want to place the bitmap and thus we can configure
those nodes appropriately and generate new names for everything else so
that nothing gets accidentally copied to wrong place.

My concern is though about the future. Since this is the first instance
of such a  migration feature which requires node names it's okay because
we can cheat by naming the destination "appropriately". The problem
will start though if there will be something else bound to the backend
of a disk addressed by node names which will have different semantics.

In that case we won't be able to cheat again.

Let's assume the following example:

qemu adds a new feature of migrating the qcow2 L2 cache. This will
obviously have different implications on when it can be used than
bitmaps.

If we'd like to use either of the features but not both together on a
node there wouldn't be a possibility to achieve that.

The thing about bitmaps is that they are not really bound to the image
itself but rather the data in the image. As long as the user provides a
image with exactly the same contents the VM can use it and the bitmap
will be correct for it.

We use this in non-shared storage migration where we by default flatten
the backing chain into a new image. In such case a bitmap is still valid
but the cache in the hypothetical example is not valid to be copied over
for the same node name.

At the very least the nuances of the capability should be documented so
that we don't have to second guess what is going to happen.

> I don't see why this is actually a terrible constraint. Even in our
> mapping proposal we're still using node-names.
> 
> 
> So here's a summary of where I stand right now:
> 
> - I want an API in QEMU that doesn't require libvirt.
> 
> - I want to accommodate libvirt, but don't understand the requirement
> that node-names must be ephemeral.

As I've outlined above, the node names must not be ephemeral but on the
same note it's then necessary to clarify when they must be stable
accross migration and when they must be different.

In the above example I'm outlining an image which has the same data but
it's a different image (it was converted for example). In that case the
bitmap migration would imply the same node name, but at the same time
the image is completely different and any other feature may be
incompatible with it.

The same is possible e.g. when you have multiple protocols to access the
same data are they the same thing and thus warrant the same node name?
or are they different.

Treating node names as ephemeral has the advantage of not trying to
assume the equivalence of the images on the migration channel and not
having to try to figure out whether they are "euqivalent enough" for the
given feature.

> 
> - I would like to define a set of default behaviors (when bitmap
> migration is enabled) that migrates only bitmaps it is confident it can
> do so correctly and error out when it cannot.

This requires also defining a set of external constraints when it will
work. Note that they can differ with other features.

> 
> - I'd like to amend the bitmap device name resolution to accommodate the
> drive-mirror case.
> 
> - Acknowledging that there might be cases where the defaults just simply
> aren't powerful enough, allow a manual configuration that allows us to
> select or deselect bitmaps and explicitly set their destination node-name.

This tangentially brings me to another question. In case when the
destination image already contains a bitmap with the same name, will the
migration of bitmaps overwrite it or merge with it?

This is again one thing that should be documented.

In the outlined case of non-shared storage migration libvirt would
obviously prefer merge or having it configurable, but as said, we have
means to work this around by renaming the bitmap temporarily  during
migration and then merging it explicitly.