Created attachment 897903 [details] xml used to define domain Description of problem: Error while defining a libvirt domain [root@bonnie i]# virsh create domain.xml error: Failed to create domain from domain.xml error: unknown OS type hvm Version-Release number of selected component (if applicable): qemu-kvm-1.6.2-5.fc20.x86_64 qemu-system-x86-1.6.2-5.fc20.x86_64 qemu-img-1.6.2-5.fc20.x86_64 qemu-common-1.6.2-5.fc20.x86_64 qemu-guest-agent-1.6.2-5.fc20.x86_64 [root@bonnie i]# lsmod | grep -i kvm kvm_intel 142832 0 kvm 430555 1 kvm_intel from /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid How reproducible: Every time Steps to Reproduce: 1. virsh create domain.xml # (attached) Actual results: Error message / no domain defined Expected results: domain defined Additional info: Looks like this is due to a recent update after downgrading to qemu-kvm-1.6.2-4.fc20.x86_64 qemu-system-x86-1.6.2-4.fc20.x86_64 qemu-guest-agent-1.6.2-5.fc20.x86_64 qemu-img-1.6.2-4.fc20.x86_64 qemu-common-1.6.2-4.fc20.x86_64 and restarting libvirtd I get [root@bonnie i]# virsh create domain.xml Domain seed created from domain.xml
This usually means something failed in QEMU when libvirt tried to probe it. When it fails, it is useful to collect 'virsh capabilities' to see if libvirt had detected any working QEMU binary. If not, then also collect the libvirtd logs from systemctl/journalctl which should show the root cause error
I was about to jump in with the same comment. Here's another comment on made on this subject: https://bugzilla.redhat.com/show_bug.cgi?id=1066630#c4 Anyway my guess is going to be you need to update glusterfs-api. https://www.redhat.com/archives/virt-tools-list/2014-May/thread.html#00033
Looks like updating glusterfs-api solved the problem The systemd journal had the following errors libvirtd[25900]: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-i386 -help) unexpected exit status 127: /usr/bin/qemu-s ystem-i386: symbol lookup error: /usr/bin/qemu-system-i386: undefined symbol: glfs_discard_async libvirtd[25900]: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-kvm -help) unexpected exit status 127: /usr/bin/qemu-system-x8 6_64: symbol lookup error: /usr/bin/qemu-system-x86_64: undefined symbol: glfs_discard_async libvirtd[25900]: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-x86_64 -help) unexpected exit status 127: /usr/bin/qemu -system-x86_64: symbol lookup error: /usr/bin/qemu-system-x86_64: undefined symbol: glfs_discard_async libvirtd[25900]: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-kvm -help) unexpected exit status 127: /usr/bin/qemu-system-x8 6_64: symbol lookup error: /usr/bin/qemu-system-x86_64: undefined symbol: glfs_discard_async libvirtd[25900]: unknown OS type hvm libvirtd[25900]: unknown OS type hvm when it wasn't working the xml output from "virsh capabilities" contained no guest elements, with the updated glusterfs-api it contains 2 guest elements one for each of <arch name='i686'> <arch name='x86_64'>
Turning this into more of an RFE against libvirt. The XML in question that Derek passed had a full emulator path included and also included the machine type / os type in the XML. So libvirt really should not have required that its default capabilities included this ostype - the XML had enough info for libvirt to work with already. We should have been able to just try to launch the guest with the QEMU binary specified and then feed back the actual error straight away. IOW, we need to change the XML parser so it doesn't do a forced lookup against the capabilties. THis may imply that other code in libvirt needs to be a bit more paranoid against some potentially missing info in the XML, it could previously assume was filled in by the XML parser.
I posted some patches upstream here: https://www.redhat.com/archives/libvir-list/2015-April/thread.html
meant to type more... first patch of that series improves the error message second patch skips the validation check at daemon startup, to fix the common issue of 'qemu breaks, restart libvirtd, virsh list is now completely empty, user confused'. it doesn't fully address dan's suggestion in comment #4 though. we could just pass the parameters on through to qemu if ostype+arch+domaintype+hvtype+machine is specified, but if someone managed to specify something bogus like ostype=xen it might blow up in weird ways. another thing to do might be to print an extra error message specifically for the case when capabilities is completely empty, since that should always indicate an abnormal situation
libvirt-1.2.13.1-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libvirt-1.2.13.1-1.fc22
Package libvirt-1.2.13.1-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-1.2.13.1-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7122/libvirt-1.2.13.1-1.fc22 then log in and leave karma (feedback).
libvirt-1.2.13.1-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.