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: | qemu | Assignee: | Markus Armbruster <armbru> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 14 | CC: | amit.shah, berrange, crobinso, dwmw2, ehabkost, gcosta, hbrock, itamar, jaswinder, jforbes, knoel, markmc, pfrields, 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 16:34:27 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Luke Macken
2010-04-13 18:27:48 UTC
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. |