Bug 1025593 - cdrom remains mounted and stable in guest after eject -f via HMP/QMP
cdrom remains mounted and stable in guest after eject -f via HMP/QMP
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: John Snow
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-31 23:42 EDT by Sibiao Luo
Modified: 2016-06-08 10:34 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-06-08 10:34:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sibiao Luo 2013-10-31 23:42:15 EDT
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 18:02:47 EDT
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 02:14:39 EDT
(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 10:34:28 EDT
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.