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

[Max Reitz]

On 23.10.19 16:10, Vladimir Sementsov-Ogievskiy wrote:
> 23.10.2019 16:56, Vladimir Sementsov-Ogievskiy wrote:
>> 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...
> 
> 
> Hmm, I see, we have command blockdev-insert-medium(id, node-name). Isn't it 
> what
> we want?

blockdev-insert-medium requires that the device be empty, so it would
need to be preceded by a blockdev-remove-medium.  And then it isn’t a
transaction...

Also, it currently is limited (intentionally) to devices with removable
media.

I suppose all of this could be changed, but basically I don’t see why we
wouldn’t use qom-set.  (Well, because it’s ugly to call this new
functionality from set_drive(), but other than that...)

(And I don’t quite know whether there isn’t more to be done for devices
that don’t inherently support removable media than just to swap the node
attached to the BB.  Don’t they also need to be drained or something?)

Max

signature.asc
Description: OpenPGP digital signature