I don't know how it happened, but the 'IDE CDROM' device on my main testing VM got its 'Cache mode' set to 'none' instead of 'default', and when this is the case, the VM persistently fails to start up. The error displayed is: Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/3 (label charserial0) qemu-system-x86_64: -drive file=/share/data/isos/19/Final-TC6/Fedora-Live-Desktop-x86_64-19-TC6-1.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw,cache=none: could not open disk image /share/data/isos/19/Final-TC6/Fedora-Live-Desktop-x86_64-19-TC6-1.iso: Invalid argument It looks like 'cache=none' is an invalid argument for IDE CD-ROM devices. Presumably this choice should not be available for such devices.
What filesystem type is /share/data/isos/19/Final-TC6 ? It is more usual that the problem is the filesystem not supporting O_DIRECT.
As dan says in comment #1, could be lack of FS support, which upstream qemu gives some better error reporting about now (at least for tmpfs). This is one of those cases where it's really difficult for virt-manager to predict what works and what doesn't work, so I prefer not to do any prediction like hiding cache for certain FS or device parameter combinations. Closing as WONTFIX, but if you find that virt-manager somehow encoded cache=none without your explicit doing, we should fix that.
It was certainly not something I ever explicitly chose myself, but I doubt I'll ever reproduce whatever circumstance led to it getting selected again, so it might be hard to debug :/
Actually, now I look at it, it seems like - on my system at least - when I add *any* storage device to a VM, even one I just created brand new, the "Cache mode" dropdown defaults to 'none'. Is that not how it's supposed to behave?
(In reply to Adam Williamson from comment #4) > Actually, now I look at it, it seems like - on my system at least - when I > add *any* storage device to a VM, even one I just created brand new, the > "Cache mode" dropdown defaults to 'none'. Is that not how it's supposed to > behave? Nope, actually I think there is a fix upstream for that too
virt-manager-0.10.0-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/virt-manager-0.10.0-3.fc19
Package virt-manager-0.10.0-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing virt-manager-0.10.0-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17599/virt-manager-0.10.0-3.fc19 then log in and leave karma (feedback).
virt-manager-0.10.0-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.