Bug 984411 - the cdrom tray status is still 0 after executing "eject" if no media is presented under Q35
the cdrom tray status is still 0 after executing "eject" if no media is prese...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: John Snow
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-15 03:59 EDT by Sibiao Luo
Modified: 2014-11-26 20:38 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-11-26 20:38:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sibiao Luo 2013-07-15 03:59:46 EDT
Description of problem:
this issue has been fixed under pc-xx machine type(bug 771610), but still hit it under Q35.
Btw, if with a cdrom media attaching, the tray_open value can be changed correctly, refer to bug 984406.

Version-Release number of selected component (if applicable):
host info:
3.10.0-0.rc7.64.el7.x86_64
qemu-kvm-1.5.1-2.el7.x86_64
guest info:
3.10.0-0.rc7.64.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot guest *without* any media cdrom under Q35.
# /usr/libexec/qemu-kvm -S -M q35...
2.check the block info via HMP and QMP monitor.
(qemu) info block
drive-system-disk: removable=0 io-status=ok file=/home/RHEL-7.0-20130628.0-Server-x86_64.qcow3 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
drive-data-disk1: removable=0 io-status=ok file=/home/my-data-disk1.qcow3 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
ide1-cd0: removable=1 locked=0 tray-open=0 [not inserted]
floppy0: removable=1 locked=0 tray-open=0 [not inserted]
sd0: removable=1 locked=0 tray-open=0 [not inserted]
3.force to eject the media device.
(qemu) eject -f ide1-cd0
4.check the tray-open value via HMP or QMP monitor.
(qemu) info block
{"execute": "query-block"}

Actual results:
(qemu) info block
ide1-cd0: removable=1 locked=0 tray-open=0 [not inserted]
...
{"execute": "query-block"}
{"device": "ide1-cd0", "locked": false, "removable": true, "tray_open": false, "type": "unknown"}, {"device": "floppy0", "locked": false, "removable": true, "tray_open": false, "type": "unknown"}

Expected results:
the tray_open value should be: tray-open=1 & tray_open": true.

Additional info:
Comment 4 juzhang 2014-11-23 20:58:52 EST
Hi Sluo,

Can you handle this issue?

Best Regards,
Junyi
Comment 6 Sibiao Luo 2014-11-26 20:38:40 EST
Since this bug was moved to qemu-kvm-rhev which did not hit it any more according to my double checking in comment #5, so I closed this issue to CURRENTRELEASE, please correct me if any mistake, thanks.

Best Regards,
sluo

Note You need to log in before you can comment on or make changes to this bug.