On Wed 25 Apr 2018 03:06:34 PM CEST, Max Reitz wrote:
>>>>>>>> One other way is to have a more generic replace-node command
>>>>>>>> which would call bdrv_replace_node(), but I don't know if we
>>>>>>>> want to expose that and I don't have any other use case for it
>>>>>>>> at the moment.
>>>>>>>
>>>>>>> I think we do want to expose that. As far as I'm informed, for
>>>>>>> graph manipulation we want a command that can replace nodes
>>>>>>> (including replacing nothing by a new node or replacing an
>>>>>>> existing node by nothing, if the parent supports that).
>>>>>>
>>>>>> Was there any discussion about this in the mailing list?
>>>>>> (proposed name for this function, features, etc.)
>>>>>
>>>>> Well, there is x-blockdev-change. But we probably want to expose
>>>>> bdrv_reopen() in the long run.
>>>>
>>>> Exposing bdrv_reopen() itself shouldn't be too much work (it takes
>>>> just two node names, or am I missing something?).
>>
>> I just realized that I meant "Exposing bdrv_replace_node()" here.
>>
>>> So from my perspective... If you think it's easy, why don't you try
>>> it and then we'll see? *cough*
>>
>> I'm doing it :-)
>>
>>>> There's still the question of how to update the backing file string
>>>> (on the overlay). stream and commit do it automatically, but if we do
>>>> bdrv_reopen() or the aforementioned modification to blockdev-mirror
>>
>> bdrv_replace_node() again
>
> But the question stands whether we need simple node replacement when
> we want bdrv_reopen() anyway. In addition, we don't need just
> replacement, we also need addition and removal (e.g. for backing files
> or quorum children) -- and especially in the case of quorum, that is
> going to be a pain (mostly naming the children).
>
> With bdrv_reopen(), we can just require the user to respecify all
> children, so we don't run into the issue of how to name things at
> least.
So in this example, if you want to replace [B] with [E] you would reopen
[C] specifying the new backing file?
[A] <- [B] <- [C] <- [D]
[E]
Berto
