Bug 581978 - "qemu: could not open disk image : No such file or directory" after fresh guest installation
"qemu: could not open disk image : No such file or directory" after fresh gue...
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Markus Armbruster
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-04-13 14:27 EDT by Luke Macken
Modified: 2016-09-19 22:40 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-09-02 12:34:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
virt-manager.log (10.41 KB, text/plain)
2010-04-13 16:09 EDT, Luke Macken
no flags Details
/var/log/libvirt/qemu/F13Beta.log (1.82 KB, text/plain)
2010-04-13 16:11 EDT, Luke Macken
no flags Details

  None (edit)
Description Luke Macken 2010-04-13 14:27:48 EDT
Description of problem:

All of my local kvm guests are now unusable, including a fresh F13 Beta kvm guest that I just installed.

When trying to start up a guest, I get the following traceback:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 589, in run_domain
  File "/usr/share/virt-manager/virtManager/domain.py", line 150, in startup
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 293, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error unable to start guest: qemu: could not open disk image : No such file or directory

The details show my VirtIO Disk 1 as /var/lib/libvirt/images/F13.img, which definitely exists:

    $ ls -lhZ /var/lib/libvirt/images/F13.img
    -rw-------. root root system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/F13.img

This is not an SELinux issue, as far as I can tell, as I am not seeing any AVCs and I tried with it disabled as well.

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


How reproducible:

Steps to Reproduce:
1. Do a fresh F13 Beta KVM installation
2. Reboot
3. Traceback appears
Comment 1 Luke Macken 2010-04-13 14:33:31 EDT
So I was able to get rid of this error by removing the virtual CD-ROM device, even though there is no device/ISO connected, and it's configured to boot from the Hard Disk.
Comment 2 Cole Robinson 2010-04-13 15:44:29 EDT
Hmm, I can't seem to reproduce.. Can you attach ~/.virt-manager/virt-manager.log so I can see what happened during all this? Can you also provide /var/log/libvirt/qemu/$vmname.log?
Comment 3 Luke Macken 2010-04-13 16:09:14 EDT
Created attachment 406338 [details]

This log shows a fresh F13 installation... restarting and triggering this Exception.  I then remove the CD rom drive, and it boots successfully.
Comment 4 Luke Macken 2010-04-13 16:11:11 EDT
Created attachment 406339 [details]
Comment 5 Cole Robinson 2010-04-13 17:08:30 EDT
Luke, if you also update libvirt using the rawvirt repo (which it looks like you are using), this issue goes away.

Basically, -drive file=,... used to mean 'no media', now qemu actually tries to open something and errors out. Technically a qemu regression, though I guess it could have been intentional (which is unfortunate since at least one libvirt version was relying on the behavior). Re-assigning to qemu.

Markus, any idea if this CLI handling change was intentional or not?
Comment 6 Markus Armbruster 2010-05-11 07:30:00 EDT
git-bisect points to

9dfd7c7a00dd700de36ca58005a7cb3934a62efb is the first bad commit
commit 9dfd7c7a00dd700de36ca58005a7cb3934a62efb
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed Jul 22 16:43:04 2009 +0200

    switch -drive to QemuOpts.
    Demo QemuOpts in action ;)
    Implementing a alternative way to specify the filename should be
    just a few lines of code now once we decided how the cmd line syntax
    should look like.
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Doesn't look like an intentional change of file= behaviour.
Comment 7 Daniel Berrange 2010-05-11 07:35:53 EDT
FYI: as per Cole's comment #5, latest libvirt takes care to omit the 'file=' parameter completely when no media is inserted, thus avoiding this change in QEMU semantics.
Comment 8 Markus Armbruster 2010-06-28 14:26:30 EDT
Upstream commit dd5b0d71d660a4e31bdf8bd0d130ce582833db9f fixes this.
Comment 9 Bug Zapper 2010-07-30 07:19:59 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
Comment 10 Justin M. Forbes 2010-09-02 12:34:27 EDT
This fix is applied in currently shipping F13 and F14 qemu packages.

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