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 1025593 - cdrom remains mounted and stable in guest after eject -f via HMP/QMP
Summary: cdrom remains mounted and stable in guest after eject -f via HMP/QMP
Keywords:
Status: CLOSED NOTABUG
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: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-01 03:42 UTC by Sibiao Luo
Modified: 2016-06-08 14:34 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-08 14:34:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Sibiao Luo 2013-11-01 03:42:15 UTC 
Description of problem:
boot guest with a ide/scsi-cd cdrom disk, it will be mounted in the guest with the udev rules, but then eject in force via HMP/QMP monitor, it still mounted stably in guest. 

Version-Release number of selected component (if applicable):
host info:
# uname -r && rpm -q qemu-kvm
3.10.0-37.el7.x86_64
qemu-kvm-1.5.3-10.el7.x86_64
guest info:
3.10.0-37.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot guest with a ide/scsi-cd cdrom disk.
e.g:...-drive file=/home/my-cdrom1.iso,media=cdrom,if=none,id=drive-disk1,format=raw,cache=none,aio=native,media=cdrom,readonly=on -device ide-drive,bus=ide.0,unit=0,drive=drive-disk1,id=disk1
2.login guest and check the cdrom info.
# ls -lh /dev/cdrom*
lrwxrwxrwx. 1 root root 3 Nov  1 19:27 /dev/cdrom -> sr0
# mount
...
/dev/sr0 on /run/media/root/CDROM type iso9660 (ro,nosuid,nodev,relatime,uid=0,gid=0,iocharset=utf8,mode=0400,dmode=0500,uhelper=udisks2)
# ls -lh /run/media/root/CDROM
total 310M
-r--------. 1 root root  39M Oct 28 15:11 kerne000.rpm
-r--------. 1 root root  29M Oct 28 15:11 kernel_3.rpm
-r--------. 1 root root 242M Oct 28 15:11 kernel_d.rpm
-r--------. 1 root root 1.1M Oct 28 15:11 kernel_h.rpm
3.eject in force via HMP/QMP monitor.
(qemu) eject -f drive-disk1
(qemu) info block
...
drive-disk1: removable=1 locked=0 tray-open=1 io-status=ok [not inserted]
4.check the cdrom info in guest.
# mount
...
/dev/sr0 on /run/media/root/CDROM type iso9660 (ro,nosuid,nodev,relatime,uid=0,gid=0,iocharset=utf8,mode=0400,dmode=0500,uhelper=udisks2)
# ls -lh /run/media/root/CDROM
total 310M
-r--------. 1 root root  39M Oct 28 15:11 kerne000.rpm
-r--------. 1 root root  29M Oct 28 15:11 kernel_3.rpm
-r--------. 1 root root 242M Oct 28 15:11 kernel_d.rpm
-r--------. 1 root root 1.1M Oct 28 15:11 kernel_h.rpm

Actual results:
after step 4, still mounted stably in guest after eject it in force via HMP/QMP monitor. 

Expected results:
it should no mounted any more in guest.

Additional info:
Comment 4 John Snow 2016-06-07 22:02:47 UTC 
directory listings may be working from cache, it's far more likely that the CDROM is actually properly ejected.

Embarrassingly, I don't have a physical CD-ROM to test with, but I advise you to replicate this test physically if you can:

- Insert a CD-ROM and mount it
- Use a paperclip to open the CD-ROM "forcibly" while the tray is locked
- use ls and verify you can still see the files,
- but try and use md5sum and see that you cannot actually read the data anymore.

I believe this is most likely NOTABUG, but if QE wants to verify the physical behavior matches the virtual behavior, they can. Otherwise, please mark CLOSED NOTABUG.

Thanks!
Comment 5 jingzhao 2016-06-08 06:14:39 UTC 
(In reply to John Snow from comment #4)
> directory listings may be working from cache, it's far more likely that the
> CDROM is actually properly ejected.
> 
> Embarrassingly, I don't have a physical CD-ROM to test with, but I advise
> you to replicate this test physically if you can:
> 
> - Insert a CD-ROM and mount it
> - Use a paperclip to open the CD-ROM "forcibly" while the tray is locked
> - use ls and verify you can still see the files,
> - but try and use md5sum and see that you cannot actually read the data
> anymore.
> 
> I believe this is most likely NOTABUG, but if QE wants to verify the
> physical behavior matches the virtual behavior, they can. Otherwise, please
> mark CLOSED NOTABUG.
> 
> Thanks!

1.I didn't try it with physical machines because paperlip is hartd to install 
2. Cdrom in guest can be ejected with libvirt tools ("virsh change-media domain file-path --eject"), and we mainly focus on the test result of libvirt from rhel7.3, so I think we can mark the issue as "WONFIX"

Thanks
Jing Zhao
Comment 6 John Snow 2016-06-08 14:34:28 UTC 
Closing on the assumption that this is NOTABUG and simply an artifact of Linux caching directory entries. On eject, files are properly unavailable in the guest as far as I can tell.

And, I assume, this matches physical behavior.
Note You need to log in before you can comment on or make changes to this bug.