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 974902 - tray-open should be 1 after ejects the passthrough CD-ROM (scsi-block) in the guest
Summary: tray-open should be 1 after ejects the passthrough CD-ROM (scsi-block) in the...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: John Snow
QA Contact: Xueqiang Wei
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-17 05:51 UTC by Sibiao Luo
Modified: 2020-01-10 10:26 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-20 18:03:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Sibiao Luo 2013-06-17 05:51:38 UTC 
Description of problem:
tray-open should be 1 after ejects the passthrough CD-ROM (scsi-block) in the guest, but if eject it var HMP monitor which has no such issue.
BTW, if use the emulated SCSI CD-ROM(scsi-cd) to test the ejecting from both HMP monitor and guest which have no such issue.

Version-Release number of selected component (if applicable):
host info:
3.10.0-0.rc5.61.el7.x86_64
qemu-kvm-1.5.0-2.el7.x86_64
seabios-1.7.2-1.el7.x86_64
guest info:
3.10.0-0.rc5.61.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.insert a CD/DVD to host.
2.boot a guest with passthrough virtio-scsi cdrom device.
eg:# /usr/libexec/qemu-kvm -cpu host -M pc-i440fx-1.5 -enable-kvm -S -m 4G -smp 4,sockets=2,cores=2,threads=1...-drive file=/dev/sr0,if=none,id=drive-cd-disk,format=raw,media=cdrom,readonly=on,cache=none,aio=native,werror=stop,rerror=stop -device virtio-scsi-pci,vectors=0,bus=pci.0,addr=0x7,id=scsi1 -device scsi-block,drive=drive-cd-disk,id=cd-disk,bus=scsi1.0,bootindex=3
3.check the block info.
(qemu) info block
4.eject and change the cdrom and check the block info var HMP.
(qemu) eject -f drive-cd-disk
(qemu) info block
(qemu) change drive-cd-disk /dev/sr0
(qemu) info block
5.make CD-ROM tray open/close in guest.
# ejcect /dev/cdrom
(qemu) info block
# ejcect -t /dev/cdrom
(qemu) info block

Actual results:
after step 4, it can eject and change the cdrom correctly.
(qemu) info block
drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok file=/dev/sr0 ro=1 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 
(qemu) eject -f drive-cd-disk
(qemu) info block
drive-cd-disk: removable=1 locked=0 tray-open=1 io-status=ok [not inserted]
(qemu) change drive-cd-disk /dev/sr0
(qemu) info block
drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok file=/dev/sr0 ro=1 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
after step 5, the CD-ROM tray of host can be opened/closed successfully, but the tray-open value fail to change to '1' after ejects the passthrough CD-ROM (scsi-block) in the guest.
guest]# eject /dev/cdrom
(qemu) info block
drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok file=/dev/sr0 ro=1 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
guest]# eject -t /dev/cdrom
(qemu) info block
drive-cd-disk: removable=1 locked=0 tray-open=0 io-status=ok file=/dev/sr0 ro=1 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0

Expected results:
after step 5, the tray-open should be 1 after ejects the passthrough CD-ROM (scsi-block) in the guest, as the CD-ROM tray of host was already opened.
guest]# eject /dev/cdrom
(qemu) info block
drive-cd-disk: removable=1 locked=0 tray-open=*1* io-status=ok file=/dev/sr0 ro=1 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
guest]# eject -t /dev/cdrom
(qemu) info block
drive-cd-disk: removable=1 locked=0 tray-open=*0* io-status=ok file=/dev/sr0 ro=1 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0

Additional info:
Comment 1 Pavel Hrdina 2013-06-24 16:13:20 UTC 
Yes, there is a bug with ejecting the pass-through SCSI CD-ROM, but this is not the case.

By running hmp/qmp commands to eject the pass-through SCSI CD-ROM it actually remove the whole CD-ROM from the guest, not only open the tray, and this behavior has been already fixed in upstream that this command fail with an error message.

But this is only temporary fix because we should really make hmp/qmp commands usable and therefore eject the tray of the pass-through SCSI CD-ROM and also show correct tray info (open/close and locked) from the real device.
Comment 4 John Snow 2017-02-16 23:26:46 UTC 
If it is not too much of a problem, could I please request a retest of this on the latest qemu-kvm? If it's still an issue, I'll acquire a CDROM to test with, but I don't have one here in the office right now that I can use for pass-through.

IMO, this is fairly low priority, however -- CDROMs are used generally only for installation media, so please take your time with the re-test.
Comment 5 Xueqiang Wei 2017-02-20 07:01:04 UTC 
CD-ROM passthrough from to the host to a guest has been disabled in Red Hat Enterprise Linux 7.0 Beta for all front ends. QEMU reports "Driver 'host_cdrom' is not whitelisted" in this scenario.

See #760885
Comment 6 John Snow 2017-02-20 18:03:17 UTC 
OK, CLOSED WONTFIX then as this is not exposed to customers anyway. Thanks for the clarification.

For anyone else who may stumble upon this bug via google, if this is still a problem, please report it to me via QEMU's upstream bug tracker at https://launchpad.net/qemu.

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