This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 581978

Summary: "qemu: could not open disk image : No such file or directory" after fresh guest installation
Product: [Fedora] Fedora Reporter: Luke Macken <lmacken>
Component: qemuAssignee: Markus Armbruster <armbru>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: amit.shah, berrange, crobinso, dwmw2, ehabkost, gcosta, hbrock, itamar, jaswinder, jforbes, knoel, markmc, scottt.tw, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-02 12:34:27 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
virt-manager.log
none
/var/log/libvirt/qemu/F13Beta.log none

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
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 150, in startup
    self._backend.create()
  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):

libvirt-0.7.1-15.fc12.x86_64
virt-manager-0.8.2-3.fc12.noarch
kernel-2.6.32.11-99.fc12.x86_64
qemu-kvm-0.12.3-2.fc12.x86_64

How reproducible:
Always

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]
virt-manager.log

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]
/var/log/libvirt/qemu/F13Beta.log
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Justin M. Forbes 2010-09-02 12:34:27 EDT
This fix is applied in currently shipping F13 and F14 qemu packages.