Hide Forgot
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:
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.
Very minor, so will postpone this to RHEL7/upstream. If there's a business case, please let us know.
Patch has been merged into upstream.
*** Bug 871321 has been marked as a duplicate of this bug. ***
This is commit 9ca111544c64b5abed2e79cf52e19a8f227b347b upstream.
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
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
(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.
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.
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.