KVM¶

For x86 based systems¶

1. To determine whether the svm or vmx CPU extensions are present, run this command:

   # grep -E 'svm|vmx' /proc/cpuinfo
   

   This command generates output if the CPU is capable of hardware-virtualization. Even if output is shown, you might still need to enable virtualization in the system BIOS for full support.

   If no output appears, consult your system documentation to ensure that your CPU and motherboard support hardware virtualization. Verify that any relevant hardware virtualization options are enabled in the system BIOS.

   The BIOS for each manufacturer is different. If you must enable virtualization in the BIOS, look for an option containing the words virtualization, VT, VMX, or SVM.

2. To list the loaded kernel modules and verify that the kvm modules are loaded, run this command:

   # lsmod | grep kvm
   

   If the output includes kvm_intel or kvm_amd, the kvm hardware virtualization modules are loaded and your kernel meets the module requirements for OpenStack Compute.

   If the output does not show that the kvm module is loaded, run this command to load it:

   # modprobe -a kvm
   

   Run the command for your CPU. For Intel, run this command:

   # modprobe -a kvm-intel
   

   For AMD, run this command:

   # modprobe -a kvm-amd
   

   Because a KVM installation can change user group membership, you might need to log in again for changes to take effect.

   If the kernel modules do not load automatically, use the procedures listed in these subsections.

If the checks indicate that required hardware virtualization support or kernel modules are disabled or unavailable, you must either enable this support on the system or find a system with this support.

If KVM acceleration is not supported, configure Compute to use a different hypervisor, such as QEMU or Xen. See QEMU or XenServer (and other XAPI based Xen variants) for details.

These procedures help you load the kernel modules for Intel-based and AMD-based processors if they do not load automatically during KVM installation.

Intel-based processors

If your compute host is Intel-based, run these commands as root to load the kernel modules:

# modprobe kvm
# modprobe kvm-intel

Add these lines to the /etc/modules file so that these modules load on reboot:

kvm
kvm-intel

AMD-based processors

If your compute host is AMD-based, run these commands as root to load the kernel modules:

# modprobe kvm
# modprobe kvm-amd

Add these lines to /etc/modules file so that these modules load on reboot:

kvm
kvm-amd

For POWER based systems¶

KVM as a hypervisor is supported on POWER system’s PowerNV platform.

1. To determine if your POWER platform supports KVM based virtualization run the following command:

   # cat /proc/cpuinfo | grep PowerNV
   

   If the previous command generates the following output, then CPU supports KVM based virtualization.

   platform: PowerNV
   

   If no output is displayed, then your POWER platform does not support KVM based hardware virtualization.

2. To list the loaded kernel modules and verify that the kvm modules are loaded, run the following command:

   # lsmod | grep kvm
   

   If the output includes kvm_hv, the kvm hardware virtualization modules are loaded and your kernel meets the module requirements for OpenStack Compute.

   If the output does not show that the kvm module is loaded, run the following command to load it:

   # modprobe -a kvm
   

   For PowerNV platform, run the following command:

   # modprobe -a kvm-hv
   

   Because a KVM installation can change user group membership, you might need to log in again for changes to take effect.

Host model (default for KVM & QEMU)¶

If your nova.conf file contains cpu_mode=host-model, libvirt identifies the CPU model in /usr/share/libvirt/cpu_map.xml file that most closely matches the host, and requests additional CPU flags to complete the match. This configuration provides the maximum functionality and performance and maintains good reliability.

With regard to enabling and facilitating live migration between compute nodes, you should assess whether host-model is suitable for your compute architecture. In general, using host-model is a safe choice if your compute node CPUs are largely identical. However, if your compute nodes span multiple processor generations, you may be better advised to select a custom CPU model.

Host pass through¶

If your nova.conf file contains cpu_mode=host-passthrough, libvirt tells KVM to pass through the host CPU with no modifications. The difference to host-model, instead of just matching feature flags, every last detail of the host CPU is matched. This gives the best performance, and can be important to some apps which check low level CPU details, but it comes at a cost with respect to migration.

In host-passthrough mode, the guest can only be live-migrated to a target host that matches the source host extremely closely. This definitely includes the physical CPU model and running microcode, and may even include the running kernel. Use this mode only if

• your compute nodes have a very large degree of homogeneity (i.e. substantially all of your compute nodes use the exact same CPU generation and model), and you make sure to only live-migrate between hosts with exactly matching kernel versions, or
• you decide, for some reason and against established best practices, that your compute infrastructure should not support any live migration at all.

Custom¶

If your nova.conf file contains cpu_mode=custom, you can explicitly specify one of the supported named models using the cpu_model configuration option. For example, to configure the KVM guests to expose Nehalem CPUs, your nova.conf file should contain:

[libvirt]
cpu_mode = custom
cpu_model = Nehalem

In selecting the custom mode, along with a libvirt.cpu_model that matches the oldest of your compute node CPUs, you can ensure that live migration between compute nodes will always be possible. However, you should ensure that the libvirt.cpu_model you select passes the correct CPU feature flags to the guest.

If you need to further tweak your CPU feature flags in the custom mode, see Set CPU feature flags.

None (default for all libvirt-driven hypervisors other than KVM & QEMU)¶

If your nova.conf file contains cpu_mode=none, libvirt does not specify a CPU model. Instead, the hypervisor chooses the default model.

Nested guest support in the KVM kernel module¶

To enable nested KVM guests, your compute node must load the kvm_intel or kvm_amd module with nested=1. You can enable the nested parameter permanently, by creating a file named /etc/modprobe.d/kvm.conf and populating it with the following content:

options kvm_intel nested=1
options kvm_amd nested=1

A reboot may be required for the change to become effective.

Nested guest support in nova.conf¶

To support nested guests, you must set your libvirt.cpu_mode configuration to one of the following options:

Host pass through

In this mode, nested virtualization is automatically enabled once the KVM kernel module is loaded with nesting support.

[libvirt]
cpu_mode = host-passthrough

However, do consider the other implications that Host pass through mode has on compute functionality.

Host model

In this mode, nested virtualization is automatically enabled once the KVM kernel module is loaded with nesting support, if the matching CPU model exposes the vmx feature flag to guests by default (you can verify this with virsh capabilities on your compute node). If your CPU model does not pass in the vmx flag, you can force it with libvirt.cpu_model_extra_flags:

[libvirt]
cpu_mode = host-model
cpu_model_extra_flags = vmx

Again, consider the other implications that apply to the Host model (default for KVM & Qemu) mode.

Custom

In custom mode, the same considerations apply as in host-model mode, but you may additionally want to ensure that libvirt passes not only the vmx, but also the pcid flag to its guests:

[libvirt]
cpu_mode = custom
cpu_model = IvyBridge
cpu_model_extra_flags = vmx,pcid

Nested guest support limitations¶

When enabling nested guests, you should be aware of (and inform your users about) certain limitations that are currently inherent to nested KVM virtualization. Most importantly, guests using nested virtualization will, while nested guests are running,

• fail to complete live migration;
• fail to resume from suspend.

See the KVM documentation for more information on these limitations.