4:46 a.m.
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
8:06 p.m.
----- Original Message -----
From: "Jared" <list-virt(a)legroom.net>
To: libvir-list(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
9:51 p.m.
On 07/21/2012 08:06 PM, Andrew Cathrow wrote:
Have a look here
https://bugzilla.redhat.com/show_bug.cgi?id=804224
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
10:15 p.m.
On 07/21/2012 08:06 PM, Andrew Cathrow wrote:
Have a look here
https://bugzilla.redhat.com/show_bug.cgi?id=804224
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
2:47 a.m.
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
4505
days inactive
4507
days old
4 comments
3 participants
participants (3)
-
Andrew Cathrow -
Jared -
Jiri Denemark