| Message ID | 54423AC9.2030302@huawei.com |
|---|---|
| State | New |
| Headers | show |
Am 18.10.2014 um 12:02 hat Weidong Huang geschrieben: > Hi ALL: > > There are two ways to eject the cdrom tray. One is by the eject's qmp commmand(eject_device). > The another one is by the guest(bdrv_eject). They have different results. Yes, they are different things. If a guest opens the tray (using bdrv_eject) and then closes it again, with no user interaction in between, the virtual media must still be in the drive and the guest must be able to access the same image again. Calling bdrv_close() in this case would be a bug. The goal of the monitor command "eject" on the other hand is to remove the medium so that the drive is empty. That a device with a closed tray has to be opened for this is only secondary. > eject_device: close the BlockDriverState(bdrv_close(bs)) > bdrv_eject: don't close the BlockDriverState, > > This is ambiguous. So libvirt can't handle some situations. > > libvirt send eject qmp command ---> qemu send eject request to guest ---> > guest respond to qemu ---> qemu emit tray_open event to libvirt ---> > libvirt will not send change qmp command if media source is null. So > the media is not be replace to the null. What is the problem that libvirt has with the guest opening the tray? I don't think libvirt should even care about that case. Kevin > So close the BlockDriverState in bdrv_eject. Thanks. > > diff --git a/block.c b/block.c > index d3aebeb..0be69de 100644 > --- a/block.c > +++ b/block.c > @@ -5276,6 +5276,10 @@ void bdrv_eject(BlockDriverState *bs, bool eject_flag) > qapi_event_send_device_tray_moved(bdrv_get_device_name(bs), > eject_flag, &error_abort); > } > + > + if (eject_flag) { > + bdrv_close(bs); > + } > } >
On 2014/10/20 17:41, Kevin Wolf wrote: > Am 18.10.2014 um 12:02 hat Weidong Huang geschrieben: >> Hi ALL: >> >> There are two ways to eject the cdrom tray. One is by the eject's qmp commmand(eject_device). >> The another one is by the guest(bdrv_eject). They have different results. > > Yes, they are different things. > > If a guest opens the tray (using bdrv_eject) and then closes it again, > with no user interaction in between, the virtual media must still be in > the drive and the guest must be able to access the same image again. > Calling bdrv_close() in this case would be a bug. > > The goal of the monitor command "eject" on the other hand is to remove > the medium so that the drive is empty. That a device with a closed tray > has to be opened for this is only secondary. Thanks for your reply. There is a problem. 1. Qemu receive the "eject" command. 2. Runs "eject_request_cb" when an eject request is issued from the monitor, the tray is closed, and the medium is locked. But the drive is not closed. 3. Guest agree with opening tray and qemu will call bdrv_eject to complete. The drive is still not close. So the result of the monitor command "eject" is not to remove the medium in this situation. > >> eject_device: close the BlockDriverState(bdrv_close(bs)) >> bdrv_eject: don't close the BlockDriverState, >> >> This is ambiguous. So libvirt can't handle some situations. >> >> libvirt send eject qmp command ---> qemu send eject request to guest ---> >> guest respond to qemu ---> qemu emit tray_open event to libvirt ---> >> libvirt will not send change qmp command if media source is null. So >> the media is not be replace to the null. > > What is the problem that libvirt has with the guest opening the tray? I > don't think libvirt should even care about that case. For example, using libvirt to change media by xml below(media source is null): <disk type='file' device='cdrom'> <driver name='qemu'/> <target dev='hdb' bus='ide'/> </disk> libivrt return ok. But media still is in the guest. This is confused. Thanks. > > Kevin > >> So close the BlockDriverState in bdrv_eject. Thanks. >> >> diff --git a/block.c b/block.c >> index d3aebeb..0be69de 100644 >> --- a/block.c >> +++ b/block.c >> @@ -5276,6 +5276,10 @@ void bdrv_eject(BlockDriverState *bs, bool eject_flag) >> qapi_event_send_device_tray_moved(bdrv_get_device_name(bs), >> eject_flag, &error_abort); >> } >> + >> + if (eject_flag) { >> + bdrv_close(bs); >> + } >> } >> > > . >
Am 20.10.2014 um 13:27 hat Weidong Huang geschrieben: > On 2014/10/20 17:41, Kevin Wolf wrote: > > > Am 18.10.2014 um 12:02 hat Weidong Huang geschrieben: > >> Hi ALL: > >> > >> There are two ways to eject the cdrom tray. One is by the eject's qmp commmand(eject_device). > >> The another one is by the guest(bdrv_eject). They have different results. > > > > Yes, they are different things. > > > > If a guest opens the tray (using bdrv_eject) and then closes it again, > > with no user interaction in between, the virtual media must still be in > > the drive and the guest must be able to access the same image again. > > Calling bdrv_close() in this case would be a bug. > > > > The goal of the monitor command "eject" on the other hand is to remove > > the medium so that the drive is empty. That a device with a closed tray > > has to be opened for this is only secondary. > > > Thanks for your reply. > > There is a problem. > > 1. Qemu receive the "eject" command. > 2. Runs "eject_request_cb" when an eject request is issued from the monitor, the tray > is closed, and the medium is locked. But the drive is not closed. > 3. Guest agree with opening tray and qemu will call bdrv_eject to complete. The drive is > still not close. > > So the result of the monitor command "eject" is not to remove the medium in this situation. Now I understand, thanks for explaining. But I think libvirt can actually work correctly with what qemu offers today. qemu returns an error if the medium cannot be removed with the 'eject' command and it only sends an eject request to the guest. With this error, libvirt can know that the DEVICE_TRAY_MOVED event doesn't mean that the medium has removed, but that it needs to issue another 'eject' command. If this isn't implemented correctly in libvirt today, this needs a libvirt fix rather than a qemu one. > >> eject_device: close the BlockDriverState(bdrv_close(bs)) > >> bdrv_eject: don't close the BlockDriverState, > >> > >> This is ambiguous. So libvirt can't handle some situations. > >> > >> libvirt send eject qmp command ---> qemu send eject request to guest ---> > >> guest respond to qemu ---> qemu emit tray_open event to libvirt ---> > >> libvirt will not send change qmp command if media source is null. So > >> the media is not be replace to the null. > > > > What is the problem that libvirt has with the guest opening the tray? I > > don't think libvirt should even care about that case. > > > For example, using libvirt to change media by xml below(media source is null): > <disk type='file' device='cdrom'> > <driver name='qemu'/> > <target dev='hdb' bus='ide'/> > </disk> > > libivrt return ok. But media still is in the guest. > This is confused. Kevin
Weidong Huang <hwd@huawei.com> writes: > On 2014/10/20 17:41, Kevin Wolf wrote: > >> Am 18.10.2014 um 12:02 hat Weidong Huang geschrieben: >>> Hi ALL: >>> >>> There are two ways to eject the cdrom tray. One is by the eject's >>> qmp commmand(eject_device). >>> The another one is by the guest(bdrv_eject). They have different results. >> >> Yes, they are different things. >> >> If a guest opens the tray (using bdrv_eject) and then closes it again, >> with no user interaction in between, the virtual media must still be in >> the drive and the guest must be able to access the same image again. >> Calling bdrv_close() in this case would be a bug. >> >> The goal of the monitor command "eject" on the other hand is to remove >> the medium so that the drive is empty. That a device with a closed tray >> has to be opened for this is only secondary. > > > Thanks for your reply. > > There is a problem. > > 1. Qemu receive the "eject" command. > 2. Runs "eject_request_cb" when an eject request is issued from the > monitor, the tray > is closed, and the medium is locked. But the drive is not closed. Yes, callback eject_request_cb() runs "when an eject request is issued from the monitor, the tray * is closed, and the medium is locked" (quoting block.h). > 3. Guest agree with opening tray and qemu will call bdrv_eject to > complete. The drive is > still not close. Yes, the guest honors the request by unlocking and opening the tray. This calls bdrv_lock_medium(), then bdrv_eject(). > So the result of the monitor command "eject" is not to remove the > medium in this situation. Correct. This is a known wart. To work around it, wait for event DEVICE_TRAY_MOVED and eject again. Yes, this is racy: the guest can reclose the tray and lock it before you get your eject in. Your patch removes this wart, but regresses other scenarios: commit 4be9762adb0947a353e6efef2fed354f69218bfb Author: Markus Armbruster <armbru@redhat.com> Date: Tue Jul 27 14:02:01 2010 +0200 block: Change bdrv_eject() not to drop the image bdrv_eject() gets called when a device model opens or closes the tray. If the block driver implements method bdrv_eject(), that method gets called. Drivers host_cdrom implements it, and it opens and closes the physical tray, and nothing else. When a device model opens, then closes the tray, media changes only if the user actively changes the physical media while the tray is open. This is matches how physical hardware behaves. If the block driver doesn't implement method bdrv_eject(), we do something quite different: opening the tray severs the connection to the image by calling bdrv_close(), and closing the tray does nothing. When the device model opens, then closes the tray, media is gone, unless the user actively inserts another one while the tray is open, with a suitable change command in the monitor. This isn't how physical hardware behaves. Rather inconvenient when programs "helpfully" eject media to give you a chance to change it. The way bdrv_eject() behaves here turns that chance into a must, which is not what these programs or their users expect. Change the default action not to call bdrv_close(). Instead, note the tray status in new BlockDriverState member tray_open. Use it in bdrv_is_inserted(). Arguably, the device models should keep track of tray status themselves. But this is less invasive. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Programs really depend on "eject, load, get the same medium back" behavior. Example: https://bugzilla.redhat.com/show_bug.cgi?id=558256 We intend to provide new commands that behave better than "eject". Don't hold your breath. >>> eject_device: close the BlockDriverState(bdrv_close(bs)) >>> bdrv_eject: don't close the BlockDriverState, >>> >>> This is ambiguous. So libvirt can't handle some situations. >>> >>> libvirt send eject qmp command ---> qemu send eject request to guest ---> >>> guest respond to qemu ---> qemu emit tray_open event to libvirt ---> >>> libvirt will not send change qmp command if media source is null. So >>> the media is not be replace to the null. >> >> What is the problem that libvirt has with the guest opening the tray? I >> don't think libvirt should even care about that case. > > > For example, using libvirt to change media by xml below(media source is null): > <disk type='file' device='cdrom'> > <driver name='qemu'/> > <target dev='hdb' bus='ide'/> > </disk> > > libivrt return ok. But media still is in the guest. > This is confused. libvirt bug, caused by the bad QEMU interface.
On 2014/10/20 19:39, Kevin Wolf wrote: > Am 20.10.2014 um 13:27 hat Weidong Huang geschrieben: >> On 2014/10/20 17:41, Kevin Wolf wrote: >> >>> Am 18.10.2014 um 12:02 hat Weidong Huang geschrieben: >>>> Hi ALL: >>>> >>>> There are two ways to eject the cdrom tray. One is by the eject's qmp commmand(eject_device). >>>> The another one is by the guest(bdrv_eject). They have different results. >>> >>> Yes, they are different things. >>> >>> If a guest opens the tray (using bdrv_eject) and then closes it again, >>> with no user interaction in between, the virtual media must still be in >>> the drive and the guest must be able to access the same image again. >>> Calling bdrv_close() in this case would be a bug. >>> >>> The goal of the monitor command "eject" on the other hand is to remove >>> the medium so that the drive is empty. That a device with a closed tray >>> has to be opened for this is only secondary. >> >> >> Thanks for your reply. >> >> There is a problem. >> >> 1. Qemu receive the "eject" command. >> 2. Runs "eject_request_cb" when an eject request is issued from the monitor, the tray >> is closed, and the medium is locked. But the drive is not closed. >> 3. Guest agree with opening tray and qemu will call bdrv_eject to complete. The drive is >> still not close. >> >> So the result of the monitor command "eject" is not to remove the medium in this situation. > > Now I understand, thanks for explaining. > > But I think libvirt can actually work correctly with what qemu offers > today. qemu returns an error if the medium cannot be removed with the > 'eject' command and it only sends an eject request to the guest. > > With this error, libvirt can know that the DEVICE_TRAY_MOVED event > doesn't mean that the medium has removed, but that it needs to issue > another 'eject' command. > > If this isn't implemented correctly in libvirt today, this needs a > libvirt fix rather than a qemu one. > OK. Thanks. I will discuss it in libvirt community. >>>> eject_device: close the BlockDriverState(bdrv_close(bs)) >>>> bdrv_eject: don't close the BlockDriverState, >>>> >>>> This is ambiguous. So libvirt can't handle some situations. >>>> >>>> libvirt send eject qmp command ---> qemu send eject request to guest ---> >>>> guest respond to qemu ---> qemu emit tray_open event to libvirt ---> >>>> libvirt will not send change qmp command if media source is null. So >>>> the media is not be replace to the null. >>> >>> What is the problem that libvirt has with the guest opening the tray? I >>> don't think libvirt should even care about that case. >> >> >> For example, using libvirt to change media by xml below(media source is null): >> <disk type='file' device='cdrom'> >> <driver name='qemu'/> >> <target dev='hdb' bus='ide'/> >> </disk> >> >> libivrt return ok. But media still is in the guest. >> This is confused. > > Kevin > > . >
On 2014/10/20 20:12, Markus Armbruster wrote: > > Correct. This is a known wart. To work around it, wait for event > DEVICE_TRAY_MOVED and eject again. Yes, this is racy: the guest can > reclose the tray and lock it before you get your eject in. Yes. You got it. But how to resolve the racy? I intend to return fail in this situation. What's your opinion? > Programs really depend on "eject, load, get the same medium back" > behavior. Example: https://bugzilla.redhat.com/show_bug.cgi?id=558256 > > We intend to provide new commands that behave better than "eject". > Don't hold your breath. Good news. I think "eject" command should not to drop the media too. It just only open the tray, and nothing else. Calling bdrv_close() could be done in "change media" command. And "change media" command also can remove the media by null path. So this problem can be resolved. What do you think of it? Thanks.
On 2014/10/20 19:39, Kevin Wolf wrote: > Am 20.10.2014 um 13:27 hat Weidong Huang geschrieben: >> On 2014/10/20 17:41, Kevin Wolf wrote: >> >>> Am 18.10.2014 um 12:02 hat Weidong Huang geschrieben: >>>> Hi ALL: >>>> >>>> There are two ways to eject the cdrom tray. One is by the eject's qmp commmand(eject_device). >>>> The another one is by the guest(bdrv_eject). They have different results. >>> >>> Yes, they are different things. >>> >>> If a guest opens the tray (using bdrv_eject) and then closes it again, >>> with no user interaction in between, the virtual media must still be in >>> the drive and the guest must be able to access the same image again. >>> Calling bdrv_close() in this case would be a bug. >>> >>> The goal of the monitor command "eject" on the other hand is to remove >>> the medium so that the drive is empty. That a device with a closed tray >>> has to be opened for this is only secondary. >> >> >> Thanks for your reply. >> >> There is a problem. >> >> 1. Qemu receive the "eject" command. >> 2. Runs "eject_request_cb" when an eject request is issued from the monitor, the tray >> is closed, and the medium is locked. But the drive is not closed. >> 3. Guest agree with opening tray and qemu will call bdrv_eject to complete. The drive is >> still not close. >> >> So the result of the monitor command "eject" is not to remove the medium in this situation. > > Now I understand, thanks for explaining. > > But I think libvirt can actually work correctly with what qemu offers > today. qemu returns an error if the medium cannot be removed with the > 'eject' command and it only sends an eject request to the guest. > > With this error, libvirt can know that the DEVICE_TRAY_MOVED event > doesn't mean that the medium has removed, but that it needs to issue > another 'eject' command. > > If this isn't implemented correctly in libvirt today, this needs a > libvirt fix rather than a qemu one. > hi all! How about fix it in libvirt? >>>> eject_device: close the BlockDriverState(bdrv_close(bs)) >>>> bdrv_eject: don't close the BlockDriverState, >>>> >>>> This is ambiguous. So libvirt can't handle some situations. >>>> >>>> libvirt send eject qmp command ---> qemu send eject request to guest ---> >>>> guest respond to qemu ---> qemu emit tray_open event to libvirt ---> >>>> libvirt will not send change qmp command if media source is null. So >>>> the media is not be replace to the null. >>> >>> What is the problem that libvirt has with the guest opening the tray? I >>> don't think libvirt should even care about that case. >> >> >> For example, using libvirt to change media by xml below(media source is null): >> <disk type='file' device='cdrom'> >> <driver name='qemu'/> >> <target dev='hdb' bus='ide'/> >> </disk> >> >> libivrt return ok. But media still is in the guest. >> This is confused. > > Kevin > > . >
On 2014/10/21 13:53, Weidong Huang wrote: > On 2014/10/20 19:39, Kevin Wolf wrote: > >> Am 20.10.2014 um 13:27 hat Weidong Huang geschrieben: >>> On 2014/10/20 17:41, Kevin Wolf wrote: >>> >>>> Am 18.10.2014 um 12:02 hat Weidong Huang geschrieben: >>>>> Hi ALL: >>>>> >>>>> There are two ways to eject the cdrom tray. One is by the eject's qmp commmand(eject_device). >>>>> The another one is by the guest(bdrv_eject). They have different results. >>>> >>>> Yes, they are different things. >>>> >>>> If a guest opens the tray (using bdrv_eject) and then closes it again, >>>> with no user interaction in between, the virtual media must still be in >>>> the drive and the guest must be able to access the same image again. >>>> Calling bdrv_close() in this case would be a bug. >>>> >>>> The goal of the monitor command "eject" on the other hand is to remove >>>> the medium so that the drive is empty. That a device with a closed tray >>>> has to be opened for this is only secondary. >>> >>> >>> Thanks for your reply. >>> >>> There is a problem. >>> >>> 1. Qemu receive the "eject" command. >>> 2. Runs "eject_request_cb" when an eject request is issued from the monitor, the tray >>> is closed, and the medium is locked. But the drive is not closed. >>> 3. Guest agree with opening tray and qemu will call bdrv_eject to complete. The drive is >>> still not close. >>> >>> So the result of the monitor command "eject" is not to remove the medium in this situation. >> >> Now I understand, thanks for explaining. >> >> But I think libvirt can actually work correctly with what qemu offers >> today. qemu returns an error if the medium cannot be removed with the >> 'eject' command and it only sends an eject request to the guest. >> >> With this error, libvirt can know that the DEVICE_TRAY_MOVED event >> doesn't mean that the medium has removed, but that it needs to issue >> another 'eject' command. >> >> If this isn't implemented correctly in libvirt today, this needs a >> libvirt fix rather than a qemu one. >> > > > hi all! > > How about fix it in libvirt? > Cc'ing Eric for more attention. Maybe He can give you some suggestion :) Best regards, -Gonglei >>>>> eject_device: close the BlockDriverState(bdrv_close(bs)) >>>>> bdrv_eject: don't close the BlockDriverState, >>>>> >>>>> This is ambiguous. So libvirt can't handle some situations. >>>>> >>>>> libvirt send eject qmp command ---> qemu send eject request to guest ---> >>>>> guest respond to qemu ---> qemu emit tray_open event to libvirt ---> >>>>> libvirt will not send change qmp command if media source is null. So >>>>> the media is not be replace to the null. >>>> >>>> What is the problem that libvirt has with the guest opening the tray? I >>>> don't think libvirt should even care about that case. >>> >>> >>> For example, using libvirt to change media by xml below(media source is null): >>> <disk type='file' device='cdrom'> >>> <driver name='qemu'/> >>> <target dev='hdb' bus='ide'/> >>> </disk> >>> >>> libivrt return ok. But media still is in the guest. >>> This is confused. >> >> Kevin >> >> . >> > > > >
Weidong Huang <hwd@huawei.com> writes: > On 2014/10/20 20:12, Markus Armbruster wrote: > >> >> Correct. This is a known wart. To work around it, wait for event >> DEVICE_TRAY_MOVED and eject again. Yes, this is racy: the guest can >> reclose the tray and lock it before you get your eject in. > > > Yes. You got it. But how to resolve the racy? > I intend to return fail in this situation. What's your opinion? I guess failure is fair then. It's close enough to the case where the guest simply refuses to open the tray. >> Programs really depend on "eject, load, get the same medium back" >> behavior. Example: https://bugzilla.redhat.com/show_bug.cgi?id=558256 >> >> We intend to provide new commands that behave better than "eject". >> Don't hold your breath. > > > Good news. > > I think "eject" command should not to drop the media too. It just only open the > tray, and nothing else. > > Calling bdrv_close() could be done in "change media" command. And "change media" > command also can remove the media by null path. > > So this problem can be resolved. What do you think of it? We want QMP "elementary" commands that do just one thing: eject medium (open tray), remove medium, insert medium, load mediun (close tray). I feel "eject medium (open tray)" should work like pressing the button on a physical drive: if the tray is unlocked, it opens, else the drive notifies the OS of the button press. The OS should then unlock and open when possible. Likewise, "remove/insert medium" should work just like they do with a physical drive: the tray needs to be open already.
On 2014/10/21 16:33, Markus Armbruster wrote: > Weidong Huang <hwd@huawei.com> writes: > >> On 2014/10/20 20:12, Markus Armbruster wrote: >> >>> >>> Correct. This is a known wart. To work around it, wait for event >>> DEVICE_TRAY_MOVED and eject again. Yes, this is racy: the guest can >>> reclose the tray and lock it before you get your eject in. >> >> >> Yes. You got it. But how to resolve the racy? >> I intend to return fail in this situation. What's your opinion? > > I guess failure is fair then. It's close enough to the case where the > guest simply refuses to open the tray. > >>> Programs really depend on "eject, load, get the same medium back" >>> behavior. Example: https://bugzilla.redhat.com/show_bug.cgi?id=558256 >>> >>> We intend to provide new commands that behave better than "eject". >>> Don't hold your breath. >> >> >> Good news. >> >> I think "eject" command should not to drop the media too. It just only open the >> tray, and nothing else. >> >> Calling bdrv_close() could be done in "change media" command. And "change media" >> command also can remove the media by null path. >> >> So this problem can be resolved. What do you think of it? > > We want QMP "elementary" commands that do just one thing: eject medium > (open tray), remove medium, insert medium, load mediun (close tray). > > I feel "eject medium (open tray)" should work like pressing the button > on a physical drive: if the tray is unlocked, it opens, else the drive > notifies the OS of the button press. The OS should then unlock and open > when possible. > > Likewise, "remove/insert medium" should work just like they do with a > physical drive: the tray needs to be open already. > Cool. Follow the physical behavior completely. Best regards, -Gonglei
On 10/21/2014 12:10 AM, Gonglei wrote: >>>> There is a problem. >>>> >>>> 1. Qemu receive the "eject" command. >>>> 2. Runs "eject_request_cb" when an eject request is issued from the monitor, the tray >>>> is closed, and the medium is locked. But the drive is not closed. >>>> 3. Guest agree with opening tray and qemu will call bdrv_eject to complete. The drive is >>>> still not close. >>>> >>>> So the result of the monitor command "eject" is not to remove the medium in this situation. >>> >>> Now I understand, thanks for explaining. >>> >>> But I think libvirt can actually work correctly with what qemu offers >>> today. qemu returns an error if the medium cannot be removed with the >>> 'eject' command and it only sends an eject request to the guest. This whole area of interaction is messy, and this is not the first time someone has tried to improve it. Is qemu actually issuing an error message in this case, and is it distinguishable from other errors? >>> >>> With this error, libvirt can know that the DEVICE_TRAY_MOVED event >>> doesn't mean that the medium has removed, but that it needs to issue >>> another 'eject' command. >>> >>> If this isn't implemented correctly in libvirt today, this needs a >>> libvirt fix rather than a qemu one. Yes, patching libvirt to recognize this situation and try a second time to remove the disk from the tray once the guest has opened the try, in order to completely close out the drive, makes sense. >>> >> >> >> hi all! >> >> How about fix it in libvirt? >> > > Cc'ing Eric for more attention. > > Maybe He can give you some suggestion :) At this point, it may be best to make sure there is a bugzilla entry against libvirt, to make sure it is not forgotten.
Eric Blake <eblake@redhat.com> writes: > On 10/21/2014 12:10 AM, Gonglei wrote: > >>>>> There is a problem. >>>>> >>>>> 1. Qemu receive the "eject" command. >>>>> 2. Runs "eject_request_cb" when an eject request is issued from >>>>> the monitor, the tray >>>>> is closed, and the medium is locked. But the drive is not closed. >>>>> 3. Guest agree with opening tray and qemu will call bdrv_eject to >>>>> complete. The drive is >>>>> still not close. >>>>> >>>>> So the result of the monitor command "eject" is not to remove the >>>>> medium in this situation. >>>> >>>> Now I understand, thanks for explaining. >>>> >>>> But I think libvirt can actually work correctly with what qemu offers >>>> today. qemu returns an error if the medium cannot be removed with the >>>> 'eject' command and it only sends an eject request to the guest. > > This whole area of interaction is messy, and this is not the first time > someone has tried to improve it. Is qemu actually issuing an error > message in this case, and is it distinguishable from other errors? 0. Guest has a medium the guest locked into its CD-ROM drive: (qemu) info block cd cd: r7.iso (raw, read-only) Removable device: locked, tray closed Using HMP because QMP's query-block dumps a lot of detail on us that isn't relevant here. 1. eject it { "execute": "eject", "arguments": { "device": "cd" } } Fails, but notifies guest: {"error": {"class": "GenericError", "desc": "Device 'cd' is locked"}} Tray stayed put: cd: r7.iso (raw, read-only) Removable device: locked, tray closed Guest reacts to the notification and duly ejects: {"timestamp": {"seconds": 1414396646, "microseconds": 494175}, "event": "DEVICE_TRAY_MOVED", "data": {"device": "cd", "tray-open": true}} Tray is now open: cd: r7.iso (raw, read-only) Removable device: not locked, tray open I actually stopped the guest around the eject command to reliably capture tray status between eject and the guest's reaction. 2. eject it again { "execute": "eject", "arguments": { "device": "cd" } } {"return": {}} Medium is now gone: cd: [not inserted] Removable device: not locked, tray open The first eject fails with GenericError, same as other errors such as "Device '%s' is not removable". I feel reporting an error in the "locked" case is actually inappropriate, because asking the guest is exactly what the command is supposed to do then. I doubt we can change the existing commands, but we can do better in the new QMP commands I mentioned upthread. I figure a new command should return a value to distinguish the two success cases "I opened the tray" and "I asked the guest to open the tray". Until such new commands are available, I'm afraid all you can do is keying on event DEVICE_TRAY_MOVED. [...]
diff --git a/block.c b/block.c index d3aebeb..0be69de 100644 --- a/block.c +++ b/block.c @@ -5276,6 +5276,10 @@ void bdrv_eject(BlockDriverState *bs, bool eject_flag) qapi_event_send_device_tray_moved(bdrv_get_device_name(bs), eject_flag, &error_abort); } + + if (eject_flag) { + bdrv_close(bs); + } }