RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 771610 - cdrom tray status is 0 after executing "eject" if no media is presented
Summary: cdrom tray status is 0 after executing "eject" if no media is presented
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: pre-dev-freeze
: 7.0
Assignee: Pavel Hrdina
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 871321 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-04 10:12 UTC by Xiaomei Gao
Modified: 2014-06-18 03:14 UTC (History)
14 users (show)

Fixed In Version: QEMU 1.3
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 10:17:54 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Xiaomei Gao 2012-01-04 10:12:30 UTC 
Description of problem:
cdrom tray status is 0 after executing "eject" if no media is presented, while
cdrom tray status is 1 if media is presented.

Version-Release number of selected component (if applicable):
# uname -r
  2.6.32-220.el6.x86_64
# rpm -qa| grep qemu-kvm
  qemu-kvm-0.12.1.2-2.213.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot a guest with media cdrom
/usr/libexec/qemu-kvm -drive file=/home/RHEL6.2-20111117.0-Server-x86_64-DVD1.iso,if=none,media=cdrom,readonly=on,format=raw,id=drive-ide1-0-0 -device ide-drive,drive=drive-ide1-0-0,id=ide1-0-0
2.(qemu) info block
drive-ide1-0-0: removable=1 locked=0 tray-open=0 file=/home/RHEL6.2-20111117.0-Server-x86_64-DVD1.iso ro=1 drv=raw encrypted=0
3.(qemu) eject drive-ide1-0-0
4.(qemu) info block
drive-ide1-0-0: removable=1 locked=0 tray-open=1 [not inserted]

5. boot a guest with no media cdrom
-drive file="",if=none,media=cdrom,readonly=on,format=raw,id=drive-ide1-0-0 -device ide-drive,drive=drive-ide1-0-0,id=ide1-0-0
6.(qemu)info block
drive-ide1-0-0: removable=1 locked=0 tray-open=0 [not inserted]
7.(qemu) eject drive-ide1-0-0
8.(qemu) info block
drive-ide1-0-0: removable=1 locked=0 tray-open=0 [not inserted]------->different
  
Actual results:
cdrom tray status is different after executing "eject" whether media is presented or not

Expected results:
cdrom tray status should be same after executing "eject" whether media is presented or not

Additional info:
Comment 2 Markus Armbruster 2012-01-12 08:37:49 UTC 
Reproduced upstream.

It's an implementation artifact.  eject calls bdrv_close() to do the work.  bdrv_close() does nothing when there's no media.  In particular, it runs the media change device callback only when there's media.  The callback makes the CD-ROM device open the virtual tray (open, because argument load is false).

The inconsistency is ugly, but I can't see how it could do real harm.
Comment 6 Ademar Reis 2012-07-02 17:43:14 UTC 
Very minor, so will postpone this to RHEL7/upstream. If there's a business case, please let us know.
Comment 7 Pavel Hrdina 2012-09-20 09:51:17 UTC 
Patch has been merged into upstream.
Comment 10 Ademar Reis 2012-11-19 21:23:34 UTC 
*** Bug 871321 has been marked as a duplicate of this bug. ***
Comment 11 Paolo Bonzini 2013-01-09 13:37:35 UTC 
This is commit 9ca111544c64b5abed2e79cf52e19a8f227b347b upstream.
Comment 12 Sibiao Luo 2013-02-18 02:22:12 UTC 
hi Paolo,

   I boot guest with a ide cdrom, the locked=0 at first, but then will change to locked=1 when the guest boot up successfully. btw, does this bug did not fixed completely or a new issue ?
host info:
# uname -r && rpm -q qemu-kvm
3.7.0-0.34.el7.x86_64
qemu-kvm-1.3.0-3.el7.x86_64
guest info:
RHEL-Server-7.0-64
eg:...-drive file=/home/my-cdrom.iso,if=none,media=cdrom,format=raw,id=drive-ide1-0-1 -device ide-drive,drive=drive-ide1-0-1,id=ide1-0-1,bus=ide.0,unit=0
(qemu) info block
drive-system-disk: removable=0 io-status=ok file=/home/RHEL-Server-7.0-64-virtio.qcow2 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
drive-data-disk: removable=0 io-status=ok file=/home/my-data-disk.qcow2 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
drive-fdc0-0-0: removable=1 locked=0 tray-open=0 file=/home/floppy.vfd ro=0 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
drive-ide1-0-1: removable=1 locked=1 tray-open=0 io-status=ok file=/home/my-cdrom.iso ro=1 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
sd0: removable=1 locked=0 tray-open=0 [not inserted]

Best Regards.
sluo
Comment 13 Markus Armbruster 2013-02-18 07:35:38 UTC 
Upstream commit 9ca11154 causes minor problems, and will probably be redone for 1.5.  I'd recommend to delay QA until then.

See http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg00953.html
Comment 14 Sibiao Luo 2013-02-18 07:48:23 UTC 
(In reply to comment #13)
> Upstream commit 9ca11154 causes minor problems, and will probably be redone
> for 1.5.  I'd recommend to delay QA until then.
> 
> See http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg00953.html
OK, thx for your reminds, our QE will wait for it.
Comment 15 Sibiao Luo 2013-04-18 08:19:20 UTC 
Verify this issue under qemu-kvm-1.4.0-2.el7.x86_64.

host info:
kernel-3.9.0-0.rc6.51.el7.x86_64
qemu-kvm-1.4.0-2.el7.x86_64
guest info:
win8 64bit

Steps:
the same to comment #0

1.boot a guest with media cdrom.
e.g:...-drive file=/home/hddsn.iso,if=none,media=cdrom,readonly=on,format=raw,id=drive-ide1-0-0 -device ide-drive,drive=drive-ide1-0-0,id=ide1-0-0
(qemu) info block
...
drive-ide1-0-0: removable=1 locked=1 tray-open=0 io-status=ok file=/home/hddsn.iso ro=1 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
2.(qemu) eject -f drive-ide1-0-0
3.(qemu) info block
...
drive-ide1-0-0: removable=1 locked=0 tray-open=1 io-status=ok [not inserted] <---tray-open=1
4.boot a guest with no media cdrom.
(qemu) info block
...
ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
5.(qemu) eject -f ide1-cd0 
6.(qemu) info block
...
ide1-cd0: removable=1 locked=0 tray-open=1 io-status=ok [not inserted]  <---tray-open=1

Result:
cdrom tray status is the same(tray-open=1) as after executing "eject" whether media is presented or not.

Base on above, this issue has been fixe correctly.
Comment 17 Ludek Smid 2014-06-13 10:17:54 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.