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 <[email protected]> > >>> 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
