Which CPU family should a RHEV3 or RHV4 cluster be set to?

Solution Verified - Updated

Environment

  • Red Hat Enterprise Virtualization (RHEV) 3.x
  • Red Hat Virtualization (RHV) 4.x

Issue

  • How are CPU families and their features handled inside of RHEV clusters?
  • Error while adding a host to RHEV3 or RHV4
State changed to non operational as host does not meet the clusters minimum cpu-level: model_SandyBridge

Resolution

  • The cluster simply needs to be set to a compatibility level equal to the oldest processor present in any hypervisor in the cluster.

    • You do not have to have all hypervisors in a cluster be the same processor family .

    • For example, if a cluster is set to 'Westmere' family compatibility, then any Intel Westmere, Sandy Bridge, Haswell, Broadwell or Skylake based hypervisors may be added to that cluster, however a Nehalem or Penryn based hypervisor may not.

  • It should be noted that Ivy Bridge processors are compatible with a Sandy Bridge compatibility level (or older). Ivy Bridge processors are a die shrink of the Sandy Bridge series, a new compatibility level was not defined. Ivy Bridge processors are not compatible with a Haswell compatibility level. However, Ivy Bridge processors are offering additional cpu flags over Sandy Bridge generation processors. Starting qemu directly, these can be activated using "qemu -cpu sandybridge,+fsgsbase,...". For specifying these in Libvirt, the <cpu><feature> Content from libvirt.org is not included.XML element can be used. This is only recommended if the application in use is really taking advantage of the additional cpu flags, otherwise plain "sandybridge" should be used.

Root Cause

  • This is to ensure a baseline of CPU features are available to the VMs in a cluster. If a VM were to migrate to a hypervisor missing the features of another hypervisor, the VM could experience corruption or a kernel panic.

  • Please see this list of processor families and the features and technologies they support. Again, processor families may different between physical hosts, but the cluster should be set to a compatibility level equal to the oldest processor of any host in the cluster.

  • The below information can be parsed from /usr/share/libvirt/cpu_map.xml

Intel CPUs:

AMD CPUs:

  • Opteron G1 : syscall nx lm
  • Opteron G2 : All G1 features plus cx16 rdtscp lahf_lm svm
  • Opteron G3 : All G2 features plus monitor popcnt abm sse4a misalignsse
  • Opteron G4 : All G2 features plus pclmuldq ssse3 sse4.1 sse4.2 popcnt aes xsave avx pdpe1gb abm sse4a misalignsse 3dnowprefetch xop fma4
  • Opteron G5 : All G4 features plus f16c fma tbm

RHV-4.3 deprecates certain CPU architectures:

  • Red Hat Virtualization (RHV) 4.3 removes support of certain CPU types including Intel Conroe and Penryn, AMD Opteron G1-3, AMD EPYC IBPB and all IBRS CPU types. The RHV administrators are notified about this change since RHV 4.2.7. See Why my RHV 4.2 cluster has Deprecated CPU warning message

  • There are two major reasons for the CPU type deprecation which is as inline:

  • The CPU types are very old and the manufacturers no longer provide security fixes. It applies to the following CPU types

    • Intel Conroe Family
    • Intel Penryn Family
    • AMD Opteron G1
    • AMD Opteron G2
    • AMD Opteron G3

  • The CPU types do not provide full protection against know CPU vulnerabilities which are now replaced by the same type including the (Speculative Store Bypass Disable) SSBD extension. For example Intel Nehalem IBRS Family is replaced by Intel Nehalem IBRS SSBD Family and AMD EPYC IBPB is replaced by AMD EPYC IBPB SSBD. It applies to the following CPU types

    • Intel Nehalem IBRS Family
    • Intel Westmere IBRS Family
    • Intel SandyBridge IBRS Family
    • Intel Haswell-noTSX IBRS Family
    • Intel Haswell IBRS Family
    • Intel Broadwell-noTSX IBRS Family
    • Intel Broadwell IBRS Family
    • Intel Skylake Client IBRS Family
    • Intel Skylake Server IBRS Family
    • AMD EPYC IBPB

  • The CPU type change is a manual task that needs to be done before raising the cluster compatibility version to 4.3. The cluster upgrade will be prevented if the CPU type of the cluster is one of the deprecated types.

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.