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