Bug 1065507
Summary: | kvm guest fails to start without optical media in host's optical drive | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | James B. Byrne <byrnejb> |
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.5 | CC: | acathrow, bsarathy, chayang, jdenemar, juzhang, mazhang, mkenneth, qzhang, sluo, virt-maint |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-03-27 10:25:33 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
James B. Byrne
2014-02-14 19:48:27 UTC
Reproduce this bug with virt-manager. Host: qemu-kvm-tools-0.12.1.2-2.415.el6_5.3.x86_64 qemu-kvm-0.12.1.2-2.415.el6_5.3.x86_64 gpxe-roms-qemu-0.9.7-6.10.el6.noarch qemu-img-0.12.1.2-2.415.el6_5.3.x86_64 qemu-kvm-debuginfo-0.12.1.2-2.415.el6_5.3.x86_64 libvirt-client-0.10.2-29.el6.x86_64 libvirt-0.10.2-29.el6.x86_64 libvirt-python-0.10.2-29.el6.x86_64 Guest: win7 Steps to Reproduce: 1. Use virt-manager to create and provision a MS-WinV7pro guest from optical media. 2. Shutdown and power off guest (virsh shutdown <domain>) 3. Remove media from optical drive on host. 4. Start guest (virsh start <domain>) Result: Start vm failed. Error starting domain: cannot open file '/dev/sr0': No medium found Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1114, in startup self._backend.create() File "/usr/lib64/python2.6/site-packages/libvirt.py", line 678, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: cannot open file '/dev/sr0': No medium found But can not reproduce this problem with qemu-kvm directly, so this bug could be a problem of libvirt. Libvirt and virt-manager version: libvirt-0.10.2-29.el6.x86_64 virt-manager-0.9.0-19.el6.x86_64 Hi, Jiri Do you think this is probably a libvirt or virt-manager issue? Correct me if I ping a wrong person :) Thanks, Qunfang There is a similar libvirt bug upstream: https://bugzilla.redhat.com/show_bug.cgi?id=868673 (In reply to James B. Byrne from comment #0) > Despite the inference I draw from the above referenced bug report, that the > <driver> tag attribute 'format' actually refers to the attribute 'type' > since the attribute format' is not found anywhere in the guest configuration > file, one cannot in fact change the driver attribute 'type' to any value > other than raw. Any attempt to do so results in this message: > > unsupported configuration: unknown driver format value 'host_cdrom' That's expected, type attribute specifies whether the image pointed to by <source> is raw, qcow2, whatever. You really want "raw" for CDROM images. > Failed. Try again? [y,n,f,?]: > > Further, the value 'f' is not permitted so one cannot forcibly save the > configuration to determine if in fact it might work. Hmm, I'm not sure what this "f" is supposed to be used for. If libvirtd fails to parse the XML (which is what happened here), there's no way we could force it to take that XML anyway. > However, if a readable medium is placed in the host's optical drive then the > guest will start using the configuration generated by virt-manager. There's an easy workaround for this. Just remove the <source .../> element (line 32 above) from the domain XML. That will provide an empty CDROM drive to the guest. *** This bug has been marked as a duplicate of bug 1019926 *** Thank you. The work-around solves the startup problem for me. |