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:
-
In this mode, the
cpu
element describes the CPU that should be presented to the guest. This is the default when nomode
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. -
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. Thematch
attribute can't be used in this mode. Specifying CPU model is not supported either, butmodel
'sfallback
attribute may still be used. Using thefeature
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 usinghost-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 usinghost-model
and usecustom
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 thehost-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> ...
-
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.
custom
host-model
host-passthrough
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
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".