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

[Vladimir Sementsov-Ogievskiy]

02.10.2019 14:11, Kevin Wolf wrote:
> Am 02.10.2019 um 12:46 hat Peter Krempa geschrieben:
>> On Tue, Oct 01, 2019 at 12:07:54 -0400, John Snow wrote:
>>>
>>>
>>> On 10/1/19 11:57 AM, Vladimir Sementsov-Ogievskiy wrote:
>>>> 01.10.2019 17:10, John Snow wrote:
>>>>>
>>>>>
>>>>> On 10/1/19 10:00 AM, Vladimir Sementsov-Ogievskiy wrote:
>>>>>>> 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.)
>>>>>> Not the name of ancestor node, it will break mapping: it must be name of 
>>>>>> the
>>>>>> node itself or name of parent (may be through several filters) 
>>>>>> block-backend
>>>>>>
>>>>>
>>>>> Ah, you are right of course -- because block-backends are the only
>>>>> "nodes" for which we actually descend the graph and add the bitmap to
>>>>> its child.
>>>>>
>>>>> So the real back-resolution mechanism is:
>>>>>
>>>
>>> Amendment:
>>>     - If our local node-name N is well-formed, use this.
>>
>> I'd like to re-iterate that the necessity to keep node names same on
>> both sides of migration is unexpected, undocumented and in some cases
>> impossible.
> 
> I think the (implicitly made) requirement is not that all node-names are
> kept the same, but only the node-names of those nodes for which
> migration transfers some state.
> 
> It seems to me that bitmap migration is the first case of putting
> something in the migration stream that isn't related to a frontend, but
> to the backend, so the usual device hierarchy to address information
> doesn't work here. And it seems the implications of this weren't really
> considered sufficiently, resulting in the design problem we're
> discussing now.
> 
> What we need to transfer is dirty bitmaps, which can be attached to any
> node in the block graph. If we accept that the way to transfer this is
> the migration stream, we need a way to tell which bitmap belongs to
> which node. Matching node-name is the obvious answer, just like a
> matching device tree hierarchy is used for frontends.
> 
> If we don't want to use the migration stream for backends, we would need
> to find another way to transfer the bitmaps. I would welcome removing
> backend data from the migration stream, but if this includes
> non-persistent bitmaps, I don't see what the alternative could be.

But how to migrate persistent bitmaps if storage is not shared?

And even with only persistent bitmaps and shared storage: bitmaps data may
be large, and storing/loading it during migration downtime will increase
it.

> 
>> If you want to mandate that they must be kept the same please document
>> it and also note the following:
>>
>> - during migrations the storage layout may change e.g. a backing chain
>>    may become flattened, thus keeping node names stable beyond the top
>>    layer is impossible
> 
> You don't want to transfer bitmaps of nodes that you're going to drop.
> I'm not an expert for these bitmaps, but I think this just means you
> would have to disable any bitmaps on the backing files to be dropped on
> the source host before you migrate.

You mean remove them.. But yes, any way it's not a problem. If corresponding
node isn't exist on target, we don't need any bitmaps for it.

> 
>> - in some cases (readonly image in a cdrom not present on destination,
>>    thus not relevant here probably) it may even become impossible to
>>    create any node thus keeping the top node may be impossible
> 
> Same thing, you don't want to transfer a bitmap for a node that
> disappears.
> 
>> - it should be documented when and why this happens and how management
>>    tools are supposed to do it
>>
>> - please let me know what's actually expected, since libvirt
>>    didn't enable blockdev yet we can fix any unexpected expectations
>>
>> - Document it so that the expectations don't change after this.
> 
> Yes, we need a good and ideally future-proof rule of which node-names
> need to stay the same. Currently it's only bitmaps, but might we get
> another feature later where we want to transfer more backend data?
> 
>> - Ideally node names will not be bound to anything and freely
>>    changeable. If necessary we can provide a map to qemu during migration
>>    which is probably less painful and more straightforward than keeping
>>    them in sync somehow ...
> 
> A map feels painful for the average user (and for the QEMU
> implementation), even if it looks convenient for libvirt. If anything,
> I'd make it optional and default to 1:1 mappings for anything that isn't
> explicitly mapped.
> 

Hmm, I don't think that optional map is painful.

What about the following:

1. If map is provided:
- migrate only bitmaps in nodes, specified by map
- bitmaps migrated only accordingly to the map, block device names are not 
involved at all

2. If map not provided:
- For nodes directly bound to named block backends, or through several filters, 
use name of this
block backend.
- For other nodes use node-name

===

And I think [2.] should be done now to fix current bug, and [1.] may be 
postponed until we
really need it.

-- 
Best regards,
Vladimir