Ganeti: describe how to change the CPU type on POWER
authorAurelien Jarno <aurelien@aurel32.net>
Sun, 3 Feb 2019 09:33:05 +0000 (10:33 +0100)
committerAurelien Jarno <aurelien@aurel32.net>
Sun, 3 Feb 2019 09:34:18 +0000 (10:34 +0100)
input/howto/install-ganeti.creole

index d88f024..cd69cbb 100644 (file)
@@ -497,6 +497,8 @@ and bus traffic. This can be done using:
 
 Modern processors come with a wide variety of additional instruction sets (SSE, AES-NI, etc.) which vary from processor to processor, but can greatly improve the performance depending on the workload. Ganeti and QEMU default to a compatible subset of cpu features called qemu64, so that if the host processor is changed, or a live migration is performed, the guest will see its CPUfeatures unchanged. This is great for compatibility but comes at a performance cost.
 
+==== On x86 ====
+
 The CPU presented to the guests can easily be changed, using the cpu_type option in Ganeti hypervisor options. However to still be able to live-migrate VMs from one host to another, the CPU presented to the guest should be the common denominator of all hosts in the cluster. Otherwise a live migration between two different CPU types could crash the instance.
 
 For homogeneous clusters it is possible to use the host cpu type:
@@ -575,6 +577,13 @@ With the SandyBridge CPU type:
   aes-256-gcm     160820.14k   424322.20k   557212.50k   599435.61k   610459.65k
 }}}
 
+==== On POWER ====
+
+There are two KVM implementations on POWER, the KVM-PR (kvm-pr.ko) one which uses the "PRoblem state" of the ppc CPUs to run the guests and the KVM-HV (kvm-hv.ko) one uses the hardware virtualization support of the POWER CPU. In the later case the guest CPU has to be of the same type as the host CPU. However, there is at least the possibility to run the guest in a backward-compatibility mode of the previous CPU generation by using the compat parameter:
+{{{
+  gnt-cluster modify -H kvm:cpu_type='host,\compat=power8'
+}}}
+
 === Add a virtio-rng device ===
 
 VirtIO RNG (random number generator) is a paravirtualized device that is exposed as a hardware RNG device to the guest. Virtio RNG just appears as a regular hardware RNG to the guest, which the kernel reads from to fill its entropy pool. Unfortunately Ganeti does not support it natively, therefore the kvm_extra option should be used. Ganeti forces the allocation of the PCI devices to specific slots, which means it is not possible to use the QEMU autoallocation and that an explicit PCI slot has to be provided. There 32 possible slots on the default QEMU machine, so we can use one of the last ones for example 0x1e.