[libvirt] Preferred CPU model not allowed by hypervisor
Hi. I'm having a weird problem where libvirt/qemu/kvm won't let me use the model processor I have defined in my domain's config file. Instead, I get the error message in libvirtd.log that: warning : x86Decode:1346 : Preferred CPU model Nehalem not allowed by hypervisor; closest supported model will be used If I review the qemu log for that particular domain, I see that my CPU has been changed to this: -cpu kvm64,+lahf_lm,+popcnt,+sse4.2,+sse4.1,+ssse3 (in other places, I see it set to core2duo rather than kvm64) However, it *should* be Nehalem. For some background, I'm running lvm on a westmere proc, which is the successor to Nehalem. I'm specifying Nehalem as the target platform, though, to make it easier to migrate to another server if necessary. I do have this same problem if I set this to Westmere, though, so it's not unique to Nehalem. As for support and capabilities, libvirt correctly detects my host CPU as Westmere: $ virsh capabilities | grep model <model>Westmere</model> qemu-kvm does (as far as I can tell) support Nehalem: $ qemu-kvm -cpu ?model | grep Nehalem x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7) Nehalem is defined in qmeu's target-x86_64.conf: grep Nehalem /etc/qemu/target-x86_64.conf name = "Nehalem" model_id = "Intel Core i7 9xx (Nehalem Class Core i7)" And if I run a cpu check on the processor, it seems to work fine: $ qemu-kvm -cpu Nehalem,check VNC server running on `127.0.0.1:5900' So, I I'm creating the new domain as a virt-install with the qemu-kvm backend as follows: virt-install --name=test --ram=1024 --arch=x86_64 --vcpus=2 --cpu=Nehalem --virt-type=kvm <SNIP> This results in the following cpu configuration: <cpu mode='custom' match='exact'> <model fallback='allow'>Nehalem</model> </cpu> But then, when I start this domain, I get the error message posted above. Any ideas what's going on here? I'm at a loss, and unfortunately I don't have much experience with kvm/libvirt just yet so I don't know what I should be focusing on for troubleshooting. Would appreciate any suggestions or guidance. Thanks. -- Jared
----- Original Message -----
From: "Jared" <list-virt@legroom.net> To: libvir-list@redhat.com Sent: Saturday, July 21, 2012 5:46:18 AM Subject: [libvirt] Preferred CPU model not allowed by hypervisor
Hi.
I'm having a weird problem where libvirt/qemu/kvm won't let me use the model processor I have defined in my domain's config file. Instead, I get the error message in libvirtd.log that:
warning : x86Decode:1346 : Preferred CPU model Nehalem not allowed by hypervisor; closest supported model will be used
If I review the qemu log for that particular domain, I see that my CPU has been changed to this:
-cpu kvm64,+lahf_lm,+popcnt,+sse4.2,+sse4.1,+ssse3
(in other places, I see it set to core2duo rather than kvm64)
However, it *should* be Nehalem. For some background, I'm running lvm on a westmere proc, which is the successor to Nehalem. I'm specifying Nehalem as the target platform, though, to make it easier to migrate to another server if necessary. I do have this same problem if I set this to Westmere, though, so it's not unique to Nehalem.
As for support and capabilities, libvirt correctly detects my host CPU as Westmere:
$ virsh capabilities | grep model <model>Westmere</model>
qemu-kvm does (as far as I can tell) support Nehalem:
$ qemu-kvm -cpu ?model | grep Nehalem x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7)
Nehalem is defined in qmeu's target-x86_64.conf:
grep Nehalem /etc/qemu/target-x86_64.conf name = "Nehalem" model_id = "Intel Core i7 9xx (Nehalem Class Core i7)"
And if I run a cpu check on the processor, it seems to work fine:
$ qemu-kvm -cpu Nehalem,check VNC server running on `127.0.0.1:5900'
So, I I'm creating the new domain as a virt-install with the qemu-kvm backend as follows:
virt-install --name=test --ram=1024 --arch=x86_64 --vcpus=2 --cpu=Nehalem --virt-type=kvm <SNIP>
This results in the following cpu configuration: <cpu mode='custom' match='exact'> <model fallback='allow'>Nehalem</model> </cpu>
But then, when I start this domain, I get the error message posted above.
Any ideas what's going on here? I'm at a loss, and unfortunately I don't have much experience with kvm/libvirt just yet so I don't know what I should be focusing on for troubleshooting. Would appreciate any suggestions or guidance.
Have a look here https://bugzilla.redhat.com/show_bug.cgi?id=804224
Thanks.
-- Jared
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 07/21/2012 08:06 PM, Andrew Cathrow wrote:
Have a look here
Thanks, Andrew. That's definitely it. I upgraded to qemu 1.1.1 and it now boots with modern CPU support. Appreciate the quick response. I did run into another problem after making this change, though it's not related to my original problem. Wanted to mention it, though, in case anyone else runs into it: Once I made this change, with the previous CPU definition I was using libvirt/qemu booted CentOS 6.3 with "-cpu Westmere" (plus a bunch of individual features). When this happened, CentOS would will hang shortly into the bootup process, as soon as it detects the CPU. Here are the last few lines I get before the hang: Setting APIC routing to flat ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 CPU0: Intel Westmere E56xx/L56xx/X56xx (Nehalem-C) stepping 01 Performance Events: Westmere events, Intel PMU driver. ... version: 2 ... bit width: 48 ... generic registers: 4 ... value mask: 0000ffffffffffff ... max period: 000000007fffffff ... fixed-purpose events: 3 ... event mask: 000000070000000f NMI watchdog enabled, takes one hw-pmu counter. If I set CPU=Nehalem and leave all other features in tact, and also add in the aes feature (which I think is the only difference between the two definition-wise), CentOS boots perfectly fine. There's clearly a bug here somewhere but I honestly have no idea where it lies. Setting CPU to Nehalem (which I planned to do anyway) is an easy workaround for me, so I'm not going to pursue this any further. If anyone does want to follow up on this, though, let me know and I'll be happy to assist where possible. P.S. As I was typing this I got one additional line on the console after a few minutes: Booting Node 0, Processors #1 Ok. Then, after a few more minutes I got a proper kernel dump: BUG: soft lockup - CPU#0 stuck for 67s! [swapper:1] Modules linked in: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.32-279.el6.x86_64 #1 Bochs Bochs <SNIP> I'll spare everyone the call trace details, but again, if anyone's interested in pursuing this just let me know and I'll be happy to provide all the details. -- Jared
On 07/21/2012 08:06 PM, Andrew Cathrow wrote:
Have a look here
Thanks, Andrew. That's definitely it. I upgraded to qemu 1.1.1 and it now boots with modern CPU support. Appreciate the quick response. I did run into another problem after making this change, though it's not related to my original problem. Wanted to mention it, though, in case anyone else runs into it: Once I made this change, with the previous CPU definition I was using libvirt/qemu booted CentOS 6.3 with "-cpu Westmere" (plus a bunch of individual features). When this happened, CentOS would will hang shortly into the bootup process, as soon as it detects the CPU. Here are the last few lines I get before the hang: Setting APIC routing to flat ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 CPU0: Intel Westmere E56xx/L56xx/X56xx (Nehalem-C) stepping 01 Performance Events: Westmere events, Intel PMU driver. ... version: 2 ... bit width: 48 ... generic registers: 4 ... value mask: 0000ffffffffffff ... max period: 000000007fffffff ... fixed-purpose events: 3 ... event mask: 000000070000000f NMI watchdog enabled, takes one hw-pmu counter. If I set CPU=Nehalem and leave all other features in tact, and also add in the aes feature (which I think is the only difference between the two definition-wise), CentOS boots perfectly fine. There's clearly a bug here somewhere but I honestly have no idea where it lies. Setting CPU to Nehalem (which I planned to do anyway) is an easy workaround for me, so I'm not going to pursue this any further. If anyone does want to follow up on this, though, let me know and I'll be happy to assist where possible. P.S. As I was typing this I got one additional line on the console after a few minutes: Booting Node 0, Processors #1 Ok. Then, after a few more minutes I got a proper kernel dump: BUG: soft lockup - CPU#0 stuck for 67s! [swapper:1] Modules linked in: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.32-279.el6.x86_64 #1 Bochs Bochs <SNIP> I'll spare everyone the call trace details, but again, if anyone's interested in pursuing this just let me know and I'll be happy to provide all the details. -- Jared
Hi, On Sat, Jul 21, 2012 at 04:46:18 -0500, Jared wrote:
I'm having a weird problem where libvirt/qemu/kvm won't let me use the model processor I have defined in my domain's config file. Instead, I get the error message in libvirtd.log that:
warning : x86Decode:1346 : Preferred CPU model Nehalem not allowed by hypervisor; closest supported model will be used
If I review the qemu log for that particular domain, I see that my CPU has been changed to this:
-cpu kvm64,+lahf_lm,+popcnt,+sse4.2,+sse4.1,+ssse3
The problem is libvirt that starts qemu-kvm with -nodefconfig (you can try running qemu-kvm -nodefconfig -cpu \? and check the list of available CPUs), which means /etc/qemu/target-x86_64.conf file is ignored by qemu-kvm. You will need very recent qemu-kvm (at least 1.1) and libvirt (0.9.13 or newer), which finally fixed this longstanding issue. Jirka
participants (3)
-
Andrew Cathrow -
Jared -
Jiri Denemark