Bug 854113 - Guest cdrom will be locked and fail to change anymore after the second time change the media
Guest cdrom will be locked and fail to change anymore after the second time c...
Status: CLOSED DUPLICATE of bug 885970
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.4
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: Pavel Hrdina
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-04 01:06 EDT by Sibiao Luo
Modified: 2012-12-11 03:00 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-11 03:00:49 EST
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 2012-09-04 01:06:23 EDT
Description of problem:
Boot a guest with a cdrom, such as cdimg.iso, and verify it  mount automatically in the guest, and then change the media for two times, it will be locked and fail to change again. I eject the media with "force" option in monitor, and it succeed,but then change the media two times, it also will be locked and fail to change again, the value of 'locked' will be changed to '1' after the second change, but why the value of 'locked' was '0' at the first time change.
BTW, there is a bug 676528 has been fixed with the issue that guest cdrom will always be locked after eject the media with 'force' option.

Version-Release number of selected component (if applicable):
host info:
# uname -r && rpm -q qemu-kvm
2.6.32-303.el6.x86_64
qemu-kvm-0.12.1.2-2.307.el6.x86_64
guest info:
# uname -r
2.6.32-303.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot a guest with cdrom.
# /usr/libexec/qemu-kvm -M rhel6.3.0 -cpu SandyBridge -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -usb -device usb-tablet,id=input0 -name virtio-scsi-pci -uuid `uuidgen` -device virtio-scsi-pci,bus=pci.0,addr=0x3,id=scsi0 -drive file=/home/RHEL-Server-6.3-64-sluo.qcow2,format=qcow2,if=none,id=drive-disk,cache=none,werror=stop,rerror=stop,aio=native -device scsi-hd,drive=drive-disk,bus=scsi0.0,scsi-id=0,lun=0,bootindex=2 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=98:3B:CB:2E:90:A8,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -serial unix:/tmp/ttyS1,server,nowait -vnc :2 -bios /usr/share/seabios/bios-pm.bin -qmp tcp:0:5555,server,nowait -boot menu=on -monitor stdio -drive file=/home/cdimg.iso,if=none,readonly=on,media=cdrom,id=drive-ide0-1-0,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0
2.wait the guest boot up and verify the filesystem was mounted automatically.
in monitor:
(qemu) info block
drive-disk: removable=0 io-status=ok file=/home/RHEL-Server-6.3-64-sluo.qcow2 ro=0 drv=qcow2 encrypted=0
drive-ide0-1-0: removable=1 locked=0 tray-open=0 io-status=ok file=/home/cdimg.iso ro=1 drv=raw encrypted=0
in guest:
# mount
...
(ro,nosuid,nodev,uhelper=udisks,uid=0,gid=0,iocharset=utf8,mode=0400,dmode=0500)
3.change the cdrom media for two time, verify the filesystem was mounted automatically every time.
(qemu) info block
drive-disk: removable=0 io-status=ok file=/home/RHEL-Server-6.3-64-sluo.qcow2 ro=0 drv=qcow2 encrypted=0
drive-ide0-1-0: removable=1 locked=0 tray-open=0 io-status=ok file=/home/cdimg.iso ro=1 drv=raw encrypted=0
...
(qemu) change drive-ide0-1-0 /home/en_win_srv_2003_r2_enterprise_x64_with_sp2_X13.iso
(qemu) info block
drive-disk: removable=0 io-status=ok file=/home/RHEL-Server-6.3-64-sluo.qcow2 ro=0 drv=qcow2 encrypted=0
drive-ide0-1-0: removable=1 locked=0 tray-open=0 io-status=ok file=/home/en_win_srv_2003_r2_enterprise_x64_with_sp2_X13.iso ro=1 drv=raw encrypted=0
...
(qemu) change drive-ide0-1-0 /home/cdimg.iso 
(qemu) info block
drive-disk: removable=0 io-status=ok file=/home/RHEL-Server-6.3-64-sluo.qcow2 ro=0 drv=qcow2 encrypted=0
drive-ide0-1-0: removable=1 locked=1 tray-open=0 io-status=ok file=/home/cdimg.iso ro=1 drv=raw encrypted=0
...
(qemu) change drive-ide0-1-0 /home/cdimg.iso 
Device 'drive-ide0-1-0' is locked
4.eject the cdrom by force and change it for two time, verify the filesystem was mounted automatically every time.
(qemu) eject -f drive-ide0-1-0
(qemu) info block
drive-disk: removable=0 io-status=ok file=/home/RHEL-Server-6.3-64-sluo.qcow2 ro=0 drv=qcow2 encrypted=0
...
(qemu) change drive-ide0-1-0 /home/cdimg.iso 
(qemu) info block
drive-disk: removable=0 io-status=ok file=/home/RHEL-Server-6.3-64-sluo.qcow2 ro=0 drv=qcow2 encrypted=0
drive-ide0-1-0: removable=1 locked=0 tray-open=0 io-status=ok file=/home/cdimg.iso ro=1 drv=raw encrypted=0
...
(qemu) change drive-ide0-1-0 /home/en_win_srv_2003_r2_enterprise_x64_with_sp2_X13.iso
(qemu) info block
drive-disk: removable=0 io-status=ok file=/home/RHEL-Server-6.3-64-sluo.qcow2 ro=0 drv=qcow2 encrypted=0
drive-ide0-1-0: removable=1 locked=1 tray-open=0 io-status=ok file=/home/en_win_srv_2003_r2_enterprise_x64_with_sp2_X13.iso ro=1 drv=raw encrypted=0
...
(qemu) change drive-ide0-1-0 /home/cdimg.iso 
Device 'drive-ide0-1-0' is locked

Actual results:
in the step 3/4, the cdrom media was locked and fail to change it again after the second time change the media.

Expected results:
can change the cdrom media freely and successfully without any problem.

Additional info:
Comment 3 Pavel Hrdina 2012-11-21 11:11:42 EST
I've done some deep investigation of this bug and I find out that this bug is probably Nautilus bug. In RHEL6 guest the change of a media is correctly detected by udev but Nautilus didn't correctly detect this change and somehow lock the media. Nautilus should unmount the old media and after that mount new media.

This bug is probably related to the Bug 742446 where the nautilus don't lock the media if it is automounted by Nautilus in kvm guest.

In RHEL7, Fedora17 and Fedora18 guests is similar Bug 878566 caused by nautilus and this bug could be repeated also on bare-metal.
Comment 4 Pavel Hrdina 2012-12-11 03:00:49 EST

*** This bug has been marked as a duplicate of bug 885970 ***

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