libvirt cpu model

http://libvirt.org/formatdomain.html

Since 0.8.5 the match attribute can be omitted and will default to exact. Since 0.9.10, an optional mode attribute may be used to make it easier to configure a guest CPU to be as close to host CPU as possible. Possible values for the mode attribute are:

custom

In this mode, the cpu element describes the CPU that should be presented to the guest. This is the default when no mode attribute is specified. This mode makes it so that a persistent guest will see the same hardware no matter what host the guest is booted on.

host-model

The host-model mode is essentially a shortcut to copying host CPU definition from capabilities XML into domain XML. Since the CPU definition is copied just before starting a domain, exactly the same XML can be used on different hosts while still providing the best guest CPU each host supports. The match attribute can't be used in this mode. Specifying CPU model is not supported either, but model's fallback attribute may still be used. Using the feature element, specific flags may be enabled or disabled specifically in addition to the host model. This may be used to fine tune features that can be emulated. (Since 1.1.1). Libvirt does not model every aspect of each CPU so the guest CPU will not match the host CPU exactly. On the other hand, the ABI provided to the guest is reproducible. During migration, complete CPU model definition is transferred to the destination host so the migrated guest will see exactly the same CPU model even if the destination host contains more capable CPUs for the running instance of the guest; but shutting down and restarting the guest may present different hardware to the guest according to the capabilities of the new host. Beware, due to the way libvirt detects host CPU and due to the fact libvirt does not talk to QEMU/KVM when creating the CPU model, CPU configuration created using host-model may not work as expected. The guest CPU may differ from the configuration and it may also confuse guest OS by using a combination of CPU features and other parameters (such as CPUID level) that don't work. Until these issues are fixed, it's a good idea to avoid using host-model and use custom mode with just the CPU model from host capabilities XML. (Since 1.2.11). PowerISA allows processors to run VMs in binary compatibility mode supporting an older version of ISA. Libvirt on PowerPC architecture uses the host-model to signify a guest mode CPU running in binary compatibility mode. Example: When a user needs a power7 VM to run in compatibility mode on a Power8 host, this can be described in XML as follows :

  <cpu mode='host-model'>    <model>power7</model>  </cpu>  ...

host-passthrough

With this mode, the CPU visible to the guest should be exactly the same as the host CPU even in the aspects that libvirt does not understand. Though the downside of this mode is that the guest environment cannot be reproduced on different hardware. Thus, if you hit any bugs, you are on your own. Further details of that CPU can be changed using feature elements.

In both host-model and host-passthrough mode, the real (approximate in host-passthrough mode) CPU definition which would be used on current host can be determined by specifying VIR_DOMAIN_XML_UPDATE_CPU flag when calling virDomainGetXMLDesc API. When running a guest that might be prone to operating system reactivation when presented with different hardware, and which will be migrated between hosts with different capabilities, you can use this output to rewrite XML to the custom mode for more robust migration.

model

The content of the model element specifies CPU model requested by the guest. The list of available CPU models and their definition can be found in cpu_map.xml file installed in libvirt's data directory. If a hypervisor is not able to use the exact CPU model, libvirt automatically falls back to a closest model supported by the hypervisor while maintaining the list of CPU features. Since 0.9.10, an optional fallback attribute can be used to forbid this behavior, in which case an attempt to start a domain requesting an unsupported CPU model will fail. Supported values for fallback attribute are: allow (this is the default), and forbid. The optional vendor_id attribute (Since 0.10.0) can be used to set the vendor id seen by the guest. It must be exactly 12 characters long. If not set the vendor id of the host is used. Typical possible values are "AuthenticAMD" and "GenuineIntel".