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 _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
