Bug 727409

Summary: Guest cdrom will always be locked after eject the media with 'force' option
Product: Red Hat Enterprise Linux 6 Reporter: Qunfang Zhang <qzhang>
Component: qemu-kvmAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: amit.shah, armbru, bcao, juzhang, michen, mkenneth, virt-maint
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: 2011-08-03 17:50:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Qunfang Zhang 2011-08-02 04:48:37 UTC
Description of problem:
Boot a guest with a cdrom, such as boot.iso. And then mount it inside guest, then the media will be in "locked" status. So I eject the media with "force" option, it succeed. But unfortunately the device will always be locked and can not change another iso file anymore even though I umount the cdrom inside guest and reboot guest.

Version-Release number of selected component (if applicable):
kernel-2.6.32-174.el6.x86_64
qemu-kvm-0.12.1.2-2.175.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Boot a guest with cdrom.
/usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic-usbdevice tablet -drive file=/home/RHEL6.1-32-virtio.qcow2,format=qcow2,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,mac=00:10:2a:25:1a:50,bus=pci.0,addr=0x6 -boot c -uuid e1345e5b-af68-443d-b29a-9d6b3928ac3a -rtc-td-hack -no-kvm-pit-reinjection -monitor stdio -qmp tcp:0:4444,server,nowait -name RHEL6.1 -drive file=/home/boot.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -vnc :10

2. mount the cdrom inside guest to /mnt and then check the block status.
{"execute":"query-block"}
{"return": [{"device": "drive-ide0-0-0", "locked": false, "removable": false, "inserted": {"ro": false, "drv": "qcow2", "encrypted": false, "file": "/home/RHEL6.1-32-virtio.qcow2"}, "type": "hd"}, {"device": "drive-ide0-1-0", "locked": true, "removable": true, "inserted": {"ro": true, "drv": "raw", "encrypted": false, "file": "/home/boot.iso"}, "type": "cdrom"}, {"device": "floppy0", "locked": false, "removable": true, "type": "floppy"}, {"device": "sd0", "locked": false, "removable": true, "type": "floppy"}]}

(The boot.iso is locked)

3.eject the cdrom with "force" option
{"execute":"eject","arguments":{"device":"drive-ide0-1-0","force":true}}
{"return": {}}

4.check the block status again.
{"execute":"query-block"}
{"return": [{"device": "drive-ide0-0-0", "locked": false, "removable": false, "inserted": {"ro": false, "drv": "qcow2", "encrypted": false, "file": "/home/RHEL6.1-32-virtio.qcow2"}, "type": "hd"}, {"device": "drive-ide0-1-0", "locked": true, "removable": true, "type": "cdrom"}, {"device": "floppy0", "locked": false, "removable": true, "type": "floppy"}, {"device": "sd0", "locked": false, "removable": true, "type": "floppy"}]}

5.umount the device inside guest and reboot guest, check the block status again.  

Actual results:
After step4 and step 5, device "drive-ide0-1-0" will always be locked and can not change another cdrom anymore.

Expected results:
After step 4, "locked" flag should be "false" and can insert the cdrom again.

Additional info:

Comment 2 Markus Armbruster 2011-08-03 17:50:19 UTC
Your expected results don't match how my laptop's real CD-ROM behaves: forcing media out with a paperclip doesn't affect the lock.

With the upstream fix I got under review, "eject -f" leaves the tray open and locked.  "change" works, and closes the tray, still locked.

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