Re: [Qemu-block] CDROM Eject behaviour

[Peter Lieven]

Am 13.03.2015 um 12:09 schrieb Kevin Wolf:
> Am 13.03.2015 um 11:46 hat Peter Lieven geschrieben:
>> Hi,
>>
>> I just stumbled across an old ticket where a user complains that an ejected 
>> CD is visible again after a reset.
>> It seems that the behaviour of qemu changed somewhen in the past (maybe 
>> years ago). I wonder
>> which behaviour would be correct or better.
>>
>> If we eject a CD with the eject command via qmp or hmp we open the tray 
>> *AND* remove the media.
>>
>> If the OS ejects a CD we just open the tray. So if the ATAPI or SCSI CDROM 
>> is resetted the tray is closed
>> and the CD is there again.
>>
>> Its like we should behave like a tray CDROM or a slot-in CDROM.
>>
>> A CD installer usually ejects the media after it has finished. Some ask to 
>> remove the media and press a key
>> some not.
>>
>> Whats your opinion?
> Are you aware of Max's series to fix and clean up media change? It also
> decomposes 'eject' into separate monitor commands that only open the
> tray, or only remove a medium from an already open tray.
>
> Anyway, I don't think it actually changes anything about the difference
> you mention above, because this is how it needs to work: The 'eject'
> monitor command is supposed to close the image file, this necessarily
> implies that the medium is removed. On the other hand, the guest can
> open the tray, close it again and expect that the medium is still there
> if the user hasn't changed it. I seem to remember that the Fedora
> installer does something like this. So in this case we can't just remove
> the medium.

This depends if we have a tray or slot in device. If you eject from a
slot in drive you can't load the media again. This is what Paolo
refers to as Desktop or Laptop CDROM.

If Max is working on that maybe it would be worth to add a switch
to say which type of CDROM you want to emulate?! Keeping the
default at Destop CDROM where eject not necessarily means remove
the media.

>
> By the way, things are getting even more interesting when the tray is
> locked. In this case, we can only send a request to eject the medium to
> the guest OS, but we don't know whether it will actually do that.
>
> I'll defer to Max for the details of all of that if they are relevant
> for you.

I was not aware of Max series, but it seems Paolos suggestion
to use the once switch solves the installer problem.

Thank you,
Peter