Re: [PATCH v0 0/2] allow to set 'drive' property on a realized block device

[Kevin Wolf <kwolf@redhat.com>]

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