KVM: Which CPU for VM ('host' vs 'kvm64') to use for web load?

Playing with Proxmox 5.0 as a hypervisor platform and set up KVM VM to serve website, I really wonder if I should use kvm64 "virtual" CPU or try to use host. To be specific, I have an 4-core CPU that's capable of hyper-threading which results in 8 cores to use in KVM (or maybe I should disable hyper-threading to get more power per core, in the end?) and I would devote most of the server's power to my website.

The ideas behind both are good:

• If I go with 'host' type CPU I'll get all the hardware power of the CPU and looks like I'll get most of it. The only question is how many cores should I set to be used by VM? If I set 8, then which core(s) will be used by KVM itself, and if I set to 7 (so one will be used only by KVM itself) then I have 1/8 of power less. Correct?

If I set CPU type to 'kvm64', then I can assign more CPU cores to VM (these cores to be virtual, so I can easily assign some like 64 or even 128 of such cores), so physical CPU be 'split' into a lot of smaller one, which may be useful for web type of load. Is my assumption correct?

What would you recommend me to choose?

Solution 1:

The Proxmox wiki addresses the issue of which CPU type to choose, in part:

Qemu can emulate a number different of CPU types from 486 to the latest Xeon processors. Each new processor generation adds new features, like hardware assisted 3d rendering, random number generation, memory protection, etc … Usually you should select for your VM a processor type which closely matches the CPU of the host system, as it means that the host CPU features (also called CPU flags ) will be available in your VMs. If you want an exact match, you can set the CPU type to host in which case the VM will have exactly the same CPU flags as your host system.

This has a downside though. If you want to do a live migration of VMs between different hosts, your VM might end up on a new system with a different CPU type. If the CPU flags passed to the guest are missing, the qemu process will stop. To remedy this Qemu has also its own CPU type kvm64, that Proxmox VE uses by defaults. kvm64 is a Pentium 4 look a like CPU type, which has a reduced CPU flags set, but is guaranteed to work everywhere.

In short, if you care about live migration and moving VMs between nodes, leave the kvm64 default. If you don’t care about live migration or have a homogeneous cluster where all nodes have the same CPU, set the CPU type to host, as in theory this will give your guests maximum performance.

However, one thing they don't mention is: If your servers all have different CPUs, you can use a more powerful virtual CPU generation than kvm64 and still do live migrations. You simply need to ensure that the virtual CPU type you choose is the oldest of all the physical CPUs in all your servers (e.g. if your oldest CPU is a Xeon E5630, you could use Westmere). This lets you have a server farm with mixed CPUs and still do live migration.

The same wiki also addresses how many virtual CPU cores to use:

It is perfectly safe if the overall number of cores of all your VMs is greater than the number of cores on the server (e.g., 4 VMs with each 4 cores on a machine with only 8 cores). In that case the host system will balance the Qemu execution threads between your server cores, just like if you were running a standard multithreaded application. However, Proxmox VE will prevent you from assigning more virtual CPU cores than physically available, as this will only bring the performance down due to the cost of context switches.

(They mean that no single VM will be allowed to have more virtual CPU cores than physical CPU cores. But several VMs added together may have a total of more virtual CPU cores than physical CPU cores.)

Keep in mind that web server loads usually aren't CPU bound, so you probably will have a lot of idle CPU anyway.

Solution 2:

For best performance host is the best option, as if the cpu has VT-x flag, it will directly be used within the virtual machine. Nothing needs to be emulated on the cpu and emulation has overhead.

The implications of this is of course if you switch the VM to a different host that has a different spec cpu, you would potentially have problems. However typically the problems would be mostly performance orientated e.g. if the new host has less clock speed, lower cache, or less accelerated instructions, it would be unlikely for the VM to fail to boot. But if it did fail, you could probably change the cpu type after migration to get a successful boot.

The kvm64 option gives you peace of mind you will never get migration problems on the cpu side, but it will not be as performant.