Red Hat Bugzilla – Bug 509337
"error: unknown OS type hvm " is threw out occasionally when defining domain
Last modified: 2012-11-22 05:59:18 EST
Description of problem:
Sometimes, when I try to create a domain on kvm hypervisor by command "virsh define xxx.xml", error message "error: unknown OS type hvm" will be threw out. Then, I checked the service libvirtd status and find that it is running. But, if I restart libvirtd service by command "service libvirtd restart", the domain can be defined successfully.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. define domain by command "virsh define rhel5u3.xml" on kvm hypervisor
sometimes, error message "error: unknown OS type hvm" will be threw out
2. check libvirtd status by command "service libvirtd status", find it is running actually
3. restart service libvirtd by command "service libvirtd restart"
4. repeat step 1 again, find the domain can be defined successfully again.
error message in step 1 will be threw out occasionally
error message should not be threw out in step 1
1, please check attachment rhel5u3.xml, it is the domain xml I've used.
2, never hit this issue on xen hypervisor
Created attachment 350258 [details]
I saw the same behaviour with 100% success even with service libvirtd restart.
However it turned out in my case that the reason was that the kvm_intel module was not loaded.
Just a note if it helps...
What's happening here is that libvirt is generating empty capabilities when it doesn't detect /dev/kvm or any qemu binaries. Then, when the we read in the XML configs at daemon start up, we check the requested <os><type> against caps, and throw "error: unknown OS type hvm"
This is confusing and not very transparent: users will then run 'virsh list --all' and not see any of there VMs! We should find a way to avoid this validation on libvirtd startup, even if capabilities are incorrectly detected. Then maybe move this check to VM start time so the user gets a proper error.
I don't think we can avoid this use of the capabilities in the parsing stage, because lots of other things depend on this lookup having been done. In particular this lets us ensure that the 'emulator' and 'machine type' fields are non-NULL for all parsed guests. Plenty of code in libvirt now assumes that is true, so changing it to allow NULLs is very risky. In addition, we also use the capabilities to canonicalize the machine type from 'pc' to 'pc-0.12' (or whatever is declared), and to determine whether the emulator supports static PCI address assignment.