Configuring the CPU model

The CPU model configuration specifies the features of the virtual CPUs that are provided to the virtual server.

• To define a CPU model with a specific set of hardware features, specify:
  1. Declare that a specific CPU model is to be configured.

     ---

     cpu mode attribute:	custom
     cpu match attribute:	exact

     ---

     (see <cpu>
  2. Specify an existing CPU model with the <model> element as a child of the <cpu> element.

     ---

     model element:

     <cpu_model>

     ---

     (see <model> as a child element of <cpu>)

     Where <cpu_model> is one of the models listed in the <domainCapabilities> XML. Issue virsh domcapabilities to display the contents of the XML file. Eligible values are specified with <model> tags that have the attribute useable="yes".

     Example: This example identifies gen16a as an eligible CPU model.

     <model usable="yes">gen16a</model>

     The model specifications are in one of the forms that follow:

     <mainframe_model>

     Specifies the default CPU features for an original mainframe hardware release. This default is the subset of features that are supported by the QEMU version of the KVM host. For example, gen15a specifies the QEMU supported CPU features of an IBM® z15™ mainframe when it first became available in September 2019.

     <mainframe_model>.<n>

     If applicable, specifies the default CPU features for the <n>th major hardware release of a mainframe model. This default is the subset of features that are supported by the QEMU version of the KVM host. For example, z14.2 specifies the QEMU supported CPU features of IBM z14 hardware with its first major update in October 2018 (informally also known as GA2).

     <mainframe_model>-base or <mainframe_model>.<n>-base

     Other than the default specifications, which depend on the QEMU version and can resolve to different subsets of features, the -base suffix specifies a fixed subset. This subset is supported by any QEMU version that supports the mainframe model. At the peril of not using the full hardware potential, the -base suffix reduces QEMU dependencies for an intended live migration.

  3. Optionally, use one or more <feature> elements as child elements of the <cpu> element. With each <feature> element, you can add or remove an individual CPU feature from the CPU model of the previous step (see <feature>).

     ---

     feature policy attribute:	require | disable
     feature name attribute:	<cpu_feature>

     ---

     Where <cpu_feature> is one of the features as listed by the qemu-system-s390x -cpu help command.
• To configure the basic set of CPU features that is provided by the hardware, specify:

  ---

  cpu mode attribute:

  host-model

  ---

  When the virtual server is started, libvirt expands the CPU model to an explicit specification in the libvirt-internal configuration. This explicit specification makes guest migration to a suitable alternative KVM host an option.

• To use the same CPU model as the KVM host, specify:

  ---

  cpu mode attribute:

  host-passthrough

  ---

  (see <cpu>)

  Other than for host-model, libvirt does not interpret the host's CPU model, and the CPU definition is not expanded in the libvirt-internal configuration. The lack of an explicit CPU specification has the following consequences:

  • After a migration to a more advanced KVM host, the virtual server can use all CPU features that the new host offers.
  • Live migration for a virtual server with this specification is highly risky because libvirt cannot assess the compatibility of the CPU model of the source and destination KVM host.