20.40. Guest Virtual Machine CPU Model Configuration
qemu64. These hypervisors perform more advanced filtering, classifying all physical CPUs into a handful of groups and have one baseline CPU model for each group that is presented to the guest virtual machine. Such behavior enables the safe migration of guest virtual machines between host physical machines, provided they all have physical CPUs that classify into the same group. libvirt does not typically enforce policy itself, rather it provides the mechanism on which the higher layers define their own required policy. Understanding how to obtain CPU model information and define a suitable guest virtual machine CPU model is critical to ensure guest virtual machine migration is successful between host physical machines. Note that a hypervisor can only emulate features that it is aware of and features that were created after the hypervisor was released may not be emulated.
20.40.2. Learning about the Host Physical Machine CPU Model
virsh capabilitiescommand displays an XML document describing the capabilities of the hypervisor connection and host physical machine. The XML schema displayed has been extended to provide information about the host physical machine CPU model. One of the challenges in describing a CPU model is that every architecture has a different approach to exposing their capabilities. QEMU/KVM and libvirt use a scheme which combines a CPU model name string, with a set of named flags.
20.40.3. Determining Support for VFIO IOMMU Devices
virsh domcapabilitiescommand to determine support for VFIO. See the following example output:
# virsh domcapabilities [...output truncated...] <enum name='pciBackend'> <value>default</value> <value>vfio</value> [...output truncated...]
Figure 20.3. Determining support for VFIO
20.40.4. Determining a Compatible CPU Model to Suit a Pool of Host Physical Machines
virsh capabilitiesis executed:
<capabilities> <host> <cpu> <arch>i686</arch> <model>pentium3</model> <topology sockets='1' cores='2' threads='1'/> <feature name='lahf_lm'/> <feature name='lm'/> <feature name='xtpr'/> <feature name='cx16'/> <feature name='ssse3'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='pni'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='sse2'/> <feature name='acpi'/> <feature name='ds'/> <feature name='clflush'/> <feature name='apic'/> </cpu> </host> </capabilities>
Figure 20.4. Pulling host physical machine's CPU model information
<capabilities> <host> <cpu> <arch>x86_64</arch> <model>phenom</model> <topology sockets='2' cores='4' threads='1'/> <feature name='osvw'/> <feature name='3dnowprefetch'/> <feature name='misalignsse'/> <feature name='sse4a'/> <feature name='abm'/> <feature name='cr8legacy'/> <feature name='extapic'/> <feature name='cmp_legacy'/> <feature name='lahf_lm'/> <feature name='rdtscp'/> <feature name='pdpe1gb'/> <feature name='popcnt'/> <feature name='cx16'/> <feature name='ht'/> <feature name='vme'/> </cpu> ...snip...
Figure 20.5. Generate CPU description from a random server
virsh cpu-comparecommand can be executed on this file:
virsh cpu-compare virsh-caps-workstation-cpu-only.xmlHost physical machine CPU is a superset of CPU described in virsh-caps-workstation-cpu-only.xml
virsh cpu-baselinecommand, on the
both-cpus.xmlwhich contains the CPU information for both machines. Running
# virsh cpu-baseline both-cpus.xmlresults in:
<cpu match='exact'> <model>pentium3</model> <feature policy='require' name='lahf_lm'/> <feature policy='require' name='lm'/> <feature policy='require' name='cx16'/> <feature policy='require' name='monitor'/> <feature policy='require' name='pni'/> <feature policy='require' name='ht'/> <feature policy='require' name='sse2'/> <feature policy='require' name='clflush'/> <feature policy='require' name='apic'/> </cpu>
Figure 20.6. Composite CPU baseline