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.