Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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

Summary:	cdrom tray status is 0 after executing "eject" if no media is presented
Product:	Red Hat Enterprise Linux 7	Reporter:	Xiaomei Gao <xigao>
Component:	qemu-kvm	Assignee:	Pavel Hrdina <phrdina>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	low	Docs Contact:
Priority:	low
Version:	7.0	CC:	acathrow, areis, armbru, bsarathy, hhuang, juzhang, michen, mkenneth, pbonzini, qzhang, rhod, sluo, virt-maint, wquan
Target Milestone:	pre-dev-freeze	Keywords:	FutureFeature
Target Release:	7.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	QEMU 1.3	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-06-13 10:17:54 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.