Bug 1025593

Summary:	cdrom remains mounted and stable in guest after eject -f via HMP/QMP
Product:	Red Hat Enterprise Linux 7	Reporter:	Sibiao Luo <sluo>
Component:	qemu-kvm-rhev	Assignee:	John Snow <jsnow>
Status:	CLOSED NOTABUG	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	chayang, hhuang, jinzhao, juzhang, michen, pbonzini, qzhang, rbalakri, virt-bugs, virt-maint, xfu
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-08 14:34:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.