Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

20.41. Configuring the Guest Virtual Machine CPU Model

For simple defaults, the guest virtual machine CPU configuration accepts the same basic XML representation as the host physical machine capabilities XML exposes. In other words, the XML from the virsh cpu-baseline command can now be copied directly into the guest virtual machine XML at the top level under the domain element. In the previous XML snippet, there are a few extra attributes available when describing a CPU in the guest virtual machine XML. These can mostly be ignored, but for the curious here is a quick description of what they do. The top level <cpu> element has an attribute called match with possible values of:
  • match='minimum' - the host physical machine CPU must have at least the CPU features described in the guest virtual machine XML. If the host physical machine has additional features beyond the guest virtual machine configuration, these will also be exposed to the guest virtual machine.
  • match='exact' - the host physical machine CPU must have at least the CPU features described in the guest virtual machine XML. If the host physical machine has additional features beyond the guest virtual machine configuration, these will be masked out from the guest virtual machine.
  • match='strict' - the host physical machine CPU must have exactly the same CPU features described in the guest virtual machine XML.
The next enhancement is that the <feature> elements can each have an extra 'policy' attribute with possible values of:
  • policy='force' - expose the feature to the guest virtual machine even if the host physical machine does not have it. This is usually only useful in the case of software emulation.

    Note

    It is possible that even using the force policy, the hypervisor may not be able to emulate the particular feature.
  • policy='require' - expose the feature to the guest virtual machine and fail if the host physical machine does not have it. This is the sensible default.
  • policy='optional' - expose the feature to the guest virtual machine if it happens to support it.
  • policy='disable' - if the host physical machine has this feature, then hide it from the guest virtual machine.
  • policy='forbid' - if the host physical machine has this feature, then fail and refuse to start the guest virtual machine.
The 'forbid' policy is for a niche scenario where an incorrectly functioning application will try to use a feature even if it is not in the CPUID mask, and you wish to prevent accidentally running the guest virtual machine on a host physical machine with that feature. The 'optional' policy has special behavior with respect to migration. When the guest virtual machine is initially started the flag is optional, but when the guest virtual machine is live migrated, this policy turns into 'require', since you cannot have features disappearing across migration.