Re: block-dirty-bitmap-add fails with "Operation not supported" in 4.2 rc5 (worked in 4.1)

[John Snow]

On 12/12/19 1:32 PM, Nir Soffer wrote:
> On Thu, Dec 12, 2019 at 2:04 PM Nir Soffer <address@hidden> wrote:
>>
>> We have a test for full backup flow testing that we can consume the
>> data using our nbd client.
>>
>> The test[0] is starting a full backup flow, based on Eric examples
>> from [1] and [2].
> 
> Looking at qemu-iotests/256, I switch the order of the actions in the
> transaction
> from:
> 
> actions = [
>     {"type": 'blockdev-backup", "data": ...},
>     { "type": "block-dirty-bitmap-add", "data": ...},
> ]
> 
> To:
> 
>  actions = [
>     { "type": "block-dirty-bitmap-add", "data": ...},
>     {"type": 'blockdev-backup", "data": ...},
> ]
> 
> And now the the tests pass with 4.2 rc5.
> 
> I'm not sure why it was ok to add the bitmap after starting the block
> job before and now it is not, but it makes sense to me.
> 

This ... might have something to do with filter nodes, I bet.

ide0-hd0 is the name of a device[*], not the name of a block graph node.
When you use such names for "node" or "node-name" parameters, they
(often) resolve to the root of the graph attached to the device.[**]

The problem is that the root node of the graph can change, especially
during the runtime of a block job, where filters might be added above
the existing graph.

Before blockdev-backup prepares itself, "ide0-hd0" has a qcow2 node at
the root of its tree. This node can be used to store persistent bitmaps.

After blockdev-backup prepares, "ide0-hd0" now has a filter node at its
root -- it no longer implicitly refers to the qcow2 node.

And that node, you may be surprised to learn, does not support adding
persistent dirty bitmaps. Oops.

What I recommend is using blockdev configuration top-to-bottom:

- Either on the CLI by using -blockdev, or
- At runtime using QMP, see the "create_target" function in iotest 256
for how I create a two-node qcow2 storage graph.

Using blockdev, you can give the nodes meaningful IDs that never change
out from under you. Then, I believe that your transaction should work in
either order.


--js


[*] I think. Or it's the name of a block-backend. Or something.

[**] More or less. It's complicated.