Re: [PATCH] blockdev: modify blockdev-change-medium to change non-removable device

[Kevin Wolf]

Am 23.10.2019 um 15:56 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 22.10.2019 14:05, Max Reitz wrote:
> > On 21.10.19 08:50, Denis Plotnikov wrote:
> >>
> >> On 18.10.2019 18:02, Max Reitz wrote:
> >>> On 18.10.19 14:09, Denis Plotnikov wrote:
> >>>> The modification is useful to workaround exclusive file access 
> >>>> restrictions,
> >>>> e.g. to implement VM migration with shared disk stored on a storage with
> >>>> the exclusive file opening model: a destination VM is started waiting for
> >>>> incomming migration with a fake image drive, and later, on the last 
> >>>> migration
> >>>> phase, the fake image file is replaced with the real one.
> >>>>
> >>>> Signed-off-by: Denis Plotnikov <address@hidden>
> >>> Isn’t this what we would want to use reopen for?
> >>>
> >>> Max
> >>
> >> Could you please explain what is "use reopen"?
> > 
> > I was thinking of using (x-)blockdev-reopen to change the file that is
> > used by the format node (e.g. from a null-co node to a real file); or to
> > change the filename of the protocol node.
> > 
> > Kevin has pointed out (on IRC) that this will not allow you to change
> > the node that is directly attached to the device.  While I don’t know
> > whether that’s really necessary in this case, if it were indeed
> > necessary, I’d prefer a method to change a guest device’s @drive option
> > because that seems more natural to me.
> > 
> > In contrast, the approach taken in this patch seems not quite right to
> > me, because it overloads the whole blockdev-change-medium command with a
> > completely new and different implementation based on whether there’s a
> > removable medium or not.  If the implementation is so different (and the
> > interface is, too, because in one path you must give @medium whereas the
> > other doesn’t evaluate it at all), it should be a new command.
> > 
> > I don’t know whether we need a new command at all, though.  On the node
> > level, we have (x-)blockdev-reopen.  So assuming we need something to
> > change the link between the guest device and the block layer, I wonder
> > whether there isn’t something similar; specifically, I’d prefer
> > something to simply change the device’s @drive option.
> 
> Ok, assume we can set @drive option with help of improved qom-set.
> But how to create this new blk? blockdev-add don't have 'id' parameter anymore
> and don't create blk...

We don't need to create a new BlockBackend. You would set the drive qdev
property to a new node name and that would just internally call
blk_remove_bs() and blk_insert_bs() for the existing BlockBackend that
is owned by the device.

Kevin