Libvirt identifies host processor as a different model from the hardware documentation

From Libvirt Wiki
Revision as of 08:12, 5 September 2012 by Marty (talk | contribs) (Different Processor Model Determined moved to Different processor model determined: I wrongly named the page at first, so the link from troubleshooting is heading somewhere else. The rename should fix that.)
Jump to: navigation, search

Different processor model determined

Symptom

Libvirt determines different processor model than the daemon is supposed to be running on. This can cause problems when comparing machines, creating clusters that expect same processor models etc. This problem is then propagated to upper layers that use libvirt to determine the processor model or ask libvirt for a best supported processor model for a guest (vdsm, oVirt etc.).

For example the user expects to see 'Westmere' in the output of the command, but the output looks like this:

$ virsh capabilities
<capabilities>

  <host>
    <uuid>604c8a12-cb5b-d911-985d-5404a67ef15d</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>Nehalem</model>
[...]

Investigation

Because libvirt compares the processor model according to its features, there is probably some feature missing. The file used for that is '/usr/share/libvirt/cpu_map.xml'. Looking at the file, there is only one difference between these models:

    <model name='Westmere'>
      <model name='Nehalem'/>
      <feature name='aes'/>
    </model>

As can be seen from this example, the processor model 'Westmere' inherits all the features from model 'Nehalem' and adds suport for AES, so let's double check that:

$ grep aes /proc/cpuinfo
$ #(Notice there was no output)

No output from the previous command means there is no support for AES and hence the libvirt identified it correctly from this point of view (if there was an output with 'aes' mentioned, that would mean a bug).

Solution

It might happen that there is a "bug in hardware", but there are some cases in which there's still a solution related to software/firmware as on few occasions reported by users this could be triggered by manipulating BIOS settings or UEFI settings. Some of these experiences follow.

Westmere or better recognized as Nehalem:

If this machine happens to be a IBM BladeCenter, you most probably need the IBM Advanced Settings Utility (ASU) from https://www-947.ibm.com/support/entry/myportal/docdisplay?lndocid=TOOL-ASU that can manipulate UEFI settings.

Instructions for 64-bit Linux host (modify according to your host machine/OS, IBM manual and your installation):

Reading the config parameter value

./asu64 show uEFI.AesEnable

Setting the value:

./asu64 set uEFI.AesEnable Enable

After the modification and host reboot the processor should have AES support.

AMD Quad Core Opteron G3 or better recognized as Opteron G2:

This is once again thanks to the AES flag, but this time it may be sometimes possible to fix this by enabling NX bit support in BIOS.