Am 02.03.2020 um 14:55 hat Denis Plotnikov geschrieben: > > > On 02.03.2020 16:38, Kevin Wolf wrote: > > Am 10.11.2019 um 20:03 hat Denis Plotnikov geschrieben: > > > This allows to replace the file on a block device and is useful > > > to workaround the cases (migration) when the VM image is placed on > > > some shared storage with exclusive file opening model but the image > > > should be open form more than one app. > > > > > > The previous version of approaching the workaround was based on the > > > "blockdev-change-medium" command modification but had some flaws: > > > * semantics: blockdev-change-medium is aimed to be used with removable > > > devices > > > only > > > * interface: it can't accept all possible combination of parameters for > > > the "drive" replacement (creation). > > > > > > More details here: http://patchwork.ozlabs.org/patch/1179329/ > > > > > > The current series suggests another approach: > > > 1. blockdev-add > > > 2. qom-set disk.drive = the blockdev added (this is what the series adds) > > Are you still planning to send another version? > > > > Kevin > Not in the near future :) There is an unresolved problem with > bitmap-migration is case of block dev replacement. > Still don't know how to do it in the proper way.
I seem to remember that in some discussion a while ago we came to the conclusion that we need a way for the managemnt tool to provide a mapping from source node-names to destination node-names. Or is the problem you mean unrelated to identifying the node to which a bitmap should belong? Kevin
