Bug 951114

Summary: cd can not be changed at runtime due to udev in guest
Product: [Fedora] Fedora Reporter: Fabian Deutsch <fdeutsch>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: berrange, crobinso, hbrock, jforbes, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-12 19:51:47 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 Fabian Deutsch 2013-04-11 13:53:02 UTC 
Description of problem:
virt-manager offers the functionality to change the CD (media in a cdrom) of a VM at runtime. This sometimes fails with the message:

libvirtError: Interner Fehler unable to execute QEMU command 'eject': Device 'drive-ide0-1-0' is locked

But the cd wasn't used in the guest os, so I wonder why qemu detected it.

Version-Release number of selected component (if applicable):
libvirt-0.10.2.4-1.fc18.x86_64
libvirt-client-0.10.2.4-1.fc18.x86_64
libvirt-daemon-0.10.2.4-1.fc18.x86_64
libvirt-daemon-config-network-0.10.2.4-1.fc18.x86_64
libvirt-daemon-config-nwfilter-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-interface-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-libxl-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-lxc-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-network-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-nodedev-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-nwfilter-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-qemu-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-secret-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-storage-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-uml-0.10.2.4-1.fc18.x86_64
libvirt-daemon-driver-xen-0.10.2.4-1.fc18.x86_64
libvirt-python-0.10.2.4-1.fc18.x86_64
ovirt-node-recipe-2.6.0-1.fc18.noarch
python-virtinst-0.600.4-1.fc18.noarch
python-virtkey-0.50-12.fc18.x86_64
virt-manager-0.9.5-1.fc18.noarch
virt-manager-common-0.9.5-1.fc18.noarch
virt-manager-tui-0.9.5-1.fc18.noarch
virt-top-1.0.8-3.fc18.x86_64
virt-viewer-0.5.4-3.fc18.x86_64
virt-what-1.12-2.fc18.x86_64

How reproducible:
always

Steps to Reproduce:
1. Create a vm with ide cdrom and virtio hd, boot order: vda, cdrom
2. Install ovirt-node-2.6.1 (http://resources.ovirt.org/releases/3.2/iso/)
3. Reboot after installation
4. Boot into ovirt-node and wait for prompt to appear
5. Go into properties of IDE CDROM 1 (hdc) and press "Disconnect"
  
Actual results:
libvirtError: Interner Fehler unable to execute QEMU command 'eject': Device 'drive-ide0-1-0' is locked
is raised

Expected results:
The media can be ejected

Additional info:
When looking insde the guest os I didn't see that /dev/sr0 was mounted, so I wonder why qemu says it's locked.

using
$ virsh change-media the-vm hdc /path/to/new/file --force
works

Connecting  a media (if no media is already connected) at runtime works
Comment 1 Cole Robinson 2013-06-12 19:51:47 UTC 
Upstream libvirt has this fixed:

commit 84c59ffaecc983083e2e885fa59c4f0ec1812656
Author: Michal Privoznik <mprivozn>
Date:   Thu Jan 24 15:14:14 2013 +0100

    qemu_hotplug: Rework media changing process


I'm duping this to a similar F19 bug but I'll backport all the relevant patches to F18 as well.

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