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

[Vladimir Sementsov-Ogievskiy]

02.03.2020 18:39, Kevin Wolf wrote:
> 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.

Yes, it's planned solution for bitmaps migration, but it doesn't help here.

> Or is the problem you mean unrelated to identifying the node to which a
> bitmap should belong?

The problem here is following:

We need to workaround migration on shared fs, which doesn't
allow to open file on node A if it is opened RW on node B
(and visa-versa).

So, we tried to start target with null-co stub instead of shared
qcow2 and than switch to correct file at some moment. The
problem with bitmaps migration is that we migrate bitmaps to
null-co and than they are lost... So we need to implement some
moving bitmaps from null-co to qcow2 node, keeping in mind that
they are in progress of migration. We didn't try to implement such
moving, it seemed too tricky.

I also had an idea of a flag for file-posix to close fd on inactivation..
But then we need to not open it when openining in inactive mode, and this
needs support in qcow2, which doesn't seem better than null-co stub.

So, I see two ways of solving this:

1. Use null-co stub and deal with moving bitmaps during postcopy
2. Move to UNOPENED mode for bdrv, which is similar to INACTIVE,
but doesn't allow to open any files on fs. We'll have to provide size
as an option anyway.. Sounds bad.

Could you give an advice?


--
Best regards,
Vladimir