Description of problem: I get the following error when I select the CPU to be Nehalem manually from the drop down in the virt-manager: libvirt.py", line 1007, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: syscall If I run the VM using qemu command line manually with -cpu Nehalem, it works perfectly. /proc/cpuinfo in the host suggests that syscall is supported feature. The host CPU is in fact Nehalem i7 920. Version-Release number of selected component (if applicable): 1.2.11 How reproducible: Everytime. Steps to Reproduce: 1. Create a VM with Nehalem CPU (or kvm64 or emu64, anything other than "hypervisor default") 2. Boot 3. Actual results: It fails to boot with above error. Expected results: It should boot. Additional info: Note that when I provide it "hypervisor default" option, it boots the VM fine and the -cpu qemu64 is used, which is sort of contrary to what choosing "qemu64" directly does (it does not boot). So, there is internal libvirt mishap somewhere.
Can you provide the domain XML generated by 'virt-manager --debug' and the output of 'cpuid --raw -1'? On the qemu command line, does -cpu Nehalem,enforce work? By default qemu silently drops unsupported features.
qemu runs fine with enforce: $ qemu-system-x86_64 -cpu Nehalem,enforce -machine accel=kvm -boot d -cdrom ubuntu-13.04-desktop-i386.iso -m 1000 I don't see any messages from qemu on the terminal and the machine boots and guest shows Nehalem 9xx in /proc/cpuinfo. CPUID: $ cpuid --raw -1 CPU: 0x00000000 0x00: eax=0x0000000b ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69 0x00000001 0x00: eax=0x000106a5 ebx=0x05100800 ecx=0x0098e3bd edx=0xbfebfbff 0x00000002 0x00: eax=0x55035a01 ebx=0x00f0b2e4 ecx=0x00000000 edx=0x09ca212c 0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000004 0x00: eax=0x1c004121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000000 0x00000004 0x01: eax=0x1c004122 ebx=0x00c0003f ecx=0x0000007f edx=0x00000000 0x00000004 0x02: eax=0x1c004143 ebx=0x01c0003f ecx=0x000001ff edx=0x00000000 0x00000004 0x03: eax=0x1c03c163 ebx=0x03c0003f ecx=0x00001fff edx=0x00000002 0x00000005 0x00: eax=0x00000040 ebx=0x00000040 ecx=0x00000003 edx=0x00001120 0x00000006 0x00: eax=0x00000003 ebx=0x00000002 ecx=0x00000001 edx=0x00000000 0x00000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x0000000a 0x00: eax=0x07300403 ebx=0x00000044 ecx=0x00000000 edx=0x00000603 0x0000000b 0x00: eax=0x00000001 ebx=0x00000002 ecx=0x00000100 edx=0x00000005 0x0000000b 0x01: eax=0x00000004 ebx=0x00000008 ecx=0x00000201 edx=0x00000005 0x80000000 0x00: eax=0x80000008 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x80000001 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000001 edx=0x28100000 0x80000002 0x00: eax=0x65746e49 ebx=0x2952286c ecx=0x726f4320 edx=0x4d542865 0x80000003 0x00: eax=0x37692029 ebx=0x55504320 ecx=0x20202020 edx=0x20202020 0x80000004 0x00: eax=0x30323920 ebx=0x20402020 ecx=0x37362e32 edx=0x007a4847 0x80000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x80000006 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x01006040 edx=0x00000000 0x80000007 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000100 0x80000008 0x00: eax=0x00003024 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x80860000 0x00: eax=0x00000001 ebx=0x00000002 ecx=0x00000100 edx=0x00000005 0xc0000000 0x00: eax=0x00000001 ebx=0x00000002 ecx=0x00000100 edx=0x00000005 > Can you provide the domain XML generated by 'virt-manager --debug' The output generated by the above is attached.
Created attachment 982381 [details] debug log from the virt-manager --debug This is run when I change the processor from "hypervisor default" to "Nehalem" manually. Any idea what n270 is? That's what's captured in the qemu:///system capabilities.
Created attachment 982383 [details] The XML of the domain I am also attaching the full XML of the domain in case its needed.
Interesting. When using the "copy host", I get n270 (same as capabilities), and as per qemu -cpu help: x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz So, libvirt thinks I have an Intel Atom processor? (and Windows refuses to boot with n270, saying Unsupported CPU.) How did it conclude that? As per cpuid, I have "Intel Core i7-900 (Bloomfield D0) / Xeon Processor 3500 (Bloomfield D0) / Xeon Processor 5500 (Gainestown D0), 45nm miscellaneous (1/ebx)"
Any idea about why libvirt thinks I have an Intel Atom CPU? Any quick change I can try. This is kind of urgent for me because I am moving a Windows VM from Virtualbox to KVM and I am in a Activation pickle and getting reminded about it. I don't want to redo that once I get the CPU sorted out and have to change it again.
(In reply to devsk from comment #2) > qemu runs fine with enforce: > > $ qemu-system-x86_64 -cpu Nehalem,enforce -machine accel=kvm -boot d -cdrom > ubuntu-13.04-desktop-i386.iso -m 1000 > > I don't see any messages from qemu on the terminal and the machine boots and > guest shows Nehalem 9xx in /proc/cpuinfo. > > CPUID: > > $ cpuid --raw -1 > CPU: > 0x80000001 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000001 > edx=0x28100000 0x800 in edx is the bit that should be set for the syscall feature. The latest model without the 'syscall' feature libvirt knows about is the atom, so it chooses that one. Though I'm not sure why qemu doesn't fail with enforce. Maybe some setting in BIOS setup disabled this feature?
May be CPUID is buggy and not reliable then? I say that because syscall shows up in the /proc/cpuinfo, which is what kernel thinks are the features supported by the CPU. Looks like that's the case. kernel thinks its there but CPUID instruction returns otherwise. # cpuid -1 --kernel|grep -i syscall SYSCALL and SYSRET instructions = true # cpuid -1 |grep -i syscall SYSCALL and SYSRET instructions = false $ grep syscall /proc/cpuinfo | head -1 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 sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid Also, I don't see vmware or virtualbox complain about this. They happily detect this CPU as i7 920 and work with it. If my BIOS setup was the issue, they won't work either. How can I work around this?
any ideas?
Working around this issue using this crude method for now (I need to move on with things, running out of time): # cat libvirt_cpu_model.patch --- cpu_map.xml.old 2014-12-19 09:32:18.000000000 -0800 +++ cpu_map.xml 2015-01-22 08:22:07.816451011 -0800 @@ -467,7 +467,6 @@ <feature name='clflush'/> <feature name='pni'/> <feature name='ssse3'/> - <feature name='syscall'/> <feature name='nx'/> <feature name='lm'/> <feature name='lahf_lm'/> I would really like for someone to help me with a proper solution to this problem. I am pretty sure I am not the first (or only) one to run Qemu using Libvirt on i7 920 CPU.
The right solution is to use the following CPU configuration in domain XML: <cpu mode="custom" match="exact"> <model fallback="forbid">Nehalem</model> <<feature policy='disable' name='syscall'/> <topology sockets="1" cores="2" threads="1"/> </cpu>
That's not the "right" solution. Its a workaround which I have to apply to *every VM* where I want Nehalem, which is worse than my work around. And yes, I want to use my native CPU in every VM! I am looking for the right solution in libvirt, where it does not discard Nehalem as Nehalem, out of the box without any workarounds. So, what's that solution? Do we trust cpuid --kernel more than CPUID instruction? How is kernel's CPUID module determining the right CPU flags? That's what we need to find out and rely on.
Or may be leave this CPU identification business to Qemu, which seems to be doing the right thing.
Is there any information lacking that I can provide that will help someone fix this issue with libvirt? I am seeing severe disk performance issues in the Windows guest which I suspect might have something to do with missing syscall feature. I have tried all combinations of IO mode (native, Posix threads), cache (none, wt, wb, ds) mode and disk bus (virtio, scsi, sata, IDE) but nothing seems to explain high IO waits in the guest. The same guest had outstanding disk IO performance in virtualbox. And I don't have any of these disk performance issues in my office servers where I use KVM regularly. So, its most likely related to the missing syscall feature for this particular host.
Any updates on this bug?
Is there any information lacking that I can provide that will help someone fix this issue with libvirt? Any inputs anyone?
Time for bi-monthly check...what can we do to make some progress on this issue? The bug is fairly understood and it doesn't even look like a hard bug to fix. So, what's the hold up?
I am also seeing this error during saves. I hadn't noticed that my managed saves were failing...:( # virsh managedsave 2 error: Failed to save domain 2 state error: Requested operation is not valid: domain has CPU feature: invtsc Any ideas?
Customary ping on this issue. Can someone please update whether this is being looked into?
I really need to know the answer to managedsave issue in comment 18. Someone please help. Its a big deterrent to be not able to save my VM during shutdown forcing hard power off right now.
I removed invtsc from the features (why is it even there when my host CPU does not support it?? and syscall should be there and its not there..:( as we figured before), and I get this: # virsh managedsave 2 error: Failed to save domain 2 state error: internal error: unable to execute QEMU command 'migrate': State blocked by non-migratable device '0000:00:06.0/ich9_ahci' What a freaky mess!!
OK. I give up on KVM on my desktop after 3 months...:) Moving my Windows VM back to Virtualbox, where it was working fine. I should have probably left it alone but KVM works so well everywhere else (no CPU detection issues and managedsave is a not used there), I thought I will give it a try on main desktop as well. Bad idea!! Closing as wontfix because I got a feeling nobody wants to really even troubleshoot the issue, let alone fix it.
This may not be useful , but I just encountered this bug and found a fix on this website : http://masysma.lima-city.de/37/how_to_transition_from_virtualbox_to_kvm.xhtml Removing the SATA controller from the VM avoided the error when saving.