Hide Forgot
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:
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!
(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
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.