Bug 906048 - Can't "connect" an ISO to a CD drive while guest is running
Can't "connect" an ISO to a CD drive while guest is running
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Privoznik
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-01-30 12:27 EST by Alan Jenkins
Modified: 2013-02-01 10:47 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-01 10:47:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alan Jenkins 2013-01-30 12:27:32 EST
Description of problem:

Can't "connect" an ISO to a CD drive while guest is running

Version-Release number of selected component (if applicable):


How reproducible: I've tried it a couple of times now & it's failed each time.

Steps to Reproduce:
1. Use virt-manager to create a Linux guest with a CD drive, connected to a specific ISO file.  (In addition to the hard disk which Linux is installed to)

2. Run "eject" in the guest.

3. Using virt-manager, "disconnect" the current ISO from the CD drive.  This change should be sucessfully applied without a reboot.

4. Now try to "connect" the ISO back to the CD drive.
Actual results:

Dialog with "These changes will take effect after the next guest shutdown", and an expandable text pane with:

internal error unable to execute QEMU command 'change': Could not open '/var/lib/libvirt/images/debian-6.0.6-amd64-businesscard.iso'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/details.py", line 2449, in _change_config_helper
  File "/usr/share/virt-manager/virtManager/domain.py", line 810, in hotplug_storage_media
  File "/usr/share/virt-manager/virtManager/domain.py", line 758, in attach_device
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 400, in attachDevice
    if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self)
libvirtError: internal error unable to execute QEMU command 'change': Could not open '/var/lib/libvirt/images/debian-6.0.6-amd64-businesscard.iso'

Expected results:

It should be possible to attach an ISO to a running guest (i.e. without having to reboot it).

Additional info:
Comment 1 Dave Allan 2013-01-30 13:24:21 EST
Putting aside the readability/accuracy of that error message for the moment, it looks to me like qemu is complaining that it can't open that file.  Is /var/lib/libvirt/images/debian-6.0.6-amd64-businesscard.iso correct (exists, perms, etc.)?
Comment 2 Michal Privoznik 2013-01-31 05:02:41 EST
Moreover, can you please attach debug logs?

Here's a little how-to if you are unfamiliar with them: http://wiki.libvirt.org/page/DebugLogs
Comment 3 Alan Jenkins 2013-01-31 05:06:55 EST
Sorry, the error's gone now :(.

Qemu should definitely have been able to read the file.  When the error was happening, I was able to bypass it by prodding virt-manager - I think just by following what the dialog said, i.e. shutting the VM down first.

[Quantification of "definitely" follows.  Probably useless unless this happens again]

The file was selected using the file browser - well, the pool browser - so it can't have been a typo.  I've previously used that ISO as the install media for a VM (though that was before I upgraded from F17).  I haven't moved/renamed the ISO since then. The exact file does exist (e.g. if I paste the filename from the error message into a terminal to run "ls" on it).

Perms on the ISO are r--r--r-- (0666), qemu.qemu.  I can read the file as an unprivileged user.  In fact I can read any of the files in images/.  Good job I don't have any sensitive info there .  I have selinux disabled.

Perms on /var/lib/libvirt/images/ are rwx--x--x, root.root.
Comment 4 Cole Robinson 2013-02-01 10:47:37 EST
Thanks for the info Alan. If you can reproduce in the future please reopen this bug.

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