Red Hat Bugzilla – Bug 581978
"qemu: could not open disk image : No such file or directory" after fresh guest installation
Last modified: 2016-09-19 22:40:37 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):
Steps to Reproduce:
1. Do a fresh F13 Beta KVM installation
3. Traceback appears
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.
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?
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.
Created attachment 406339 [details]
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?
git-bisect points to
9dfd7c7a00dd700de36ca58005a7cb3934a62efb is the first bad commit
Author: Gerd Hoffmann <firstname.lastname@example.org>
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 <email@example.com>
Signed-off-by: Anthony Liguori <firstname.lastname@example.org>
Doesn't look like an intentional change of file= behaviour.
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.
Upstream commit dd5b0d71d660a4e31bdf8bd0d130ce582833db9f fixes this.
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:
This fix is applied in currently shipping F13 and F14 qemu packages.