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
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] 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.
Created attachment 406339 [details] /var/log/libvirt/qemu/F13Beta.log
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 commit 9dfd7c7a00dd700de36ca58005a7cb3934a62efb Author: Gerd Hoffmann <kraxel> 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> Signed-off-by: Anthony Liguori <aliguori.com> 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This fix is applied in currently shipping F13 and F14 qemu packages.