Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event

[Kevin Wolf <kwolf@redhat.com>]

Am 24.01.2012 21:03, schrieb Eric Blake:
> On 01/24/2012 11:16 AM, Luiz Capitulino wrote:
>> Libvirt wants to be notified when the guest ejects a medium, so that
>> it can update its view of the guest.
>>
>> This code has been originally written by Daniel Berrange. It adds
>> the event to IDE and SCSI emulation.
>>
>> Please, note that this only covers guest initiated ejects, that's,
>> the QMP/HMP commands 'eject' and 'change' are not covered.

What's the reason for this behaviour? It feels inconsistent.

Also, I seem to remember that once we had discussed some kind of a "tray
status (open/closed) changed" event, which would be more generic.

>> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> 
> Reviewed-by: Eric Blake <eblake@redhat.com>
> 
>>  
>> +BLOCK_MEDIUM_EJECT
>> +------------------
>> +
>> +Emitted when the guest succeeds ejecting a medium. If the device has a tray,
> 
> s/succeeds ejecting/succeeds at ejecting/
> 
> Since libvirt is also tracking whether it makes 'eject' and 'change'
> monitor commands, and can also do a query when reconnecting to the
> monitor after a libvirtd restart to see if state changed in the meantime
> (when an event was lost), this should be sufficient for libvirt to have
> an accurate picture of the device state.
> 
> I do have to wonder, however, if we also need an event for when the
> guest initiates a tray lock or tray unlock event, in order to track
> whether plain eject will work or whether a forced eject to override the
> tray lock would be required.

The tray is usually locked for a reason, so I would vote against libvirt
automagically overriding it. Note that you don't really need a
lock/unlock event for implementing it, you could just always pass
force=true (or do it after you got QERR_DEVICE_LOCKED).

The only reasonable thing for a management tool to do with a lock/unlock
event would be updating some icon in a GUI or something like that.

Kevin