On 06/19/2013 05:32 AM, Michael Giardino wrote:
Sorry to blow up everyone's email on this but I tried something new and found a different problem. I uninstalled all the debian package (libvirt, kvm, qemu, virt-manager, etc.) and then remade all the packages and installed them. Haswell again shows up in virt-manager, but now any CPU I choose including kvm64 and qemu64 give the same error:
root@mal:~# virsh create /etc/libvirt/qemu/debian7-nonsmp.xml 2013-06-19 03:09:42.836+0000: 24248: info : libvirt version: 1.0.6 2013-06-19 03:09:42.836+0000: 24248: warning : virLogParseDefaultPriority:1581 : Ignoring invalid log level setting error: Failed to create domain from /etc/libvirt/qemu/debian7-nonsmp.xml error: internal error Cannot find suitable CPU model for given data
I guess you probably wanted to show that old, "working", domain cannot be defined, but I can't leave following not mentioned. If the machine is defined in /etc/libvirt already, it is loaded upon libvirtd startup, you shouldn't use those files directly, but instead of that use 'virsh start <domain>'
This is using the old "working" xml configuration. I then let virt-manager create a new one by installing a new VM using the qcow2 image from before. If I use the new one created by virt-manager I get the same error. The only major difference I see in the two xmls is
<os> <type arch='x86_64' machine='pc-i440fx-1.5'>hvm</type> <boot dev='hd'/> </os>
This has nothing to do with the CPU model, the reason this is different is that by default the newest machine type is selected to incorporate newest qemu features & settings which we simply cannot explain to end user.
in the new one compared to the old one below.
I'm starting to think I've hosed the whole thing and need to delete everything, remove with configuration files, and start over.
I'll check that flags for you, but in the meantime, is there a possibility that /etc/libvirt/cpu_map.xml is somehow screwed up in Debian packaging? [...]
eax in eax ebx ecx edx 00000000 0000000d 756e6547 6c65746e 49656e69 00000001 000306c3 01100800 7ffafbff bfebfbff 00000002 76036301 00f0b5ff 00000000 00c10000 00000003 00000000 00000000 00000000 00000000 00000004 00000000 00000000 00000000 00000000 00000005 00000040 00000040 00000003 00042120 00000006 00000077 00000002 00000009 00000000 00000007 00000000 00000000 00000000 00000000
From the looks of it, I'd guess both libvirt and cpuid are misdetecting Intel instructions like invpcid etc. The cpuid program doesn't clean ecx, but we do clear e[bcd]x registers before calling cpuid.
I'm looking into kernel flag detection to see how they do it (since it is visible in /proc/cpuinfo), because I can't see any other reason why this should fail. Could you create a bug for this issue in the meantime? Thanks, Martin