Last week we had a customer with a Proxmox hyper-converged cluster to run their virtual machines who had notable performance problems. If you are not familiar with Proxmox just think of it as a free version of VMware, or Hyper-V with SCCM VM Manager.
The fundamental issue was that even though a number of their Windows VM’s didn’t do very much and had 4 CPU cores that several times a day the CPU would spike to or near 100%. The client thought that adding more CPU cores would help and of course it would but it didn’t seem to be the root problem given that they already have a fair number of cores and weren’t doing very much.
Upon a deeper inspection we found two notable issues:
A “Common KVM Processor” is a generic CPU model used in virtual machines (VMs) running on Kernel-based Virtual Machine (KVM) hypervisors, like Proxmox.
This generic model ensures compatibility and stability across different hardware platforms, but it does not leverage the advanced features (and often even the common features) of the host CPU. For better performance, you can configure the VM to use the “host” CPU model, which passes through the host’s CPU features to the VM.
If you’re using Proxmox or another virtualization platform, you can change the CPU type in the VM settings to match the host platforms underlying CPU’s to improve performance. However, IF the nodes in your cluster are not running the same physical CPU’s and are not at the same firmware version it is possible live migrations from one host node to another may be problematic. It is not common to have different nodes with different CPU’s or firmware, so this is not likely a problem for you… but it is certainly possible.
In our clients case, they had Xeon E5-2650 v2 CPU’s. Switching from a generic “Common KVM Processor” to the actual underlying Intel Xeon E5-2650 v2 CPUs will result in a noticeable performance improvements because:
To change the CPU type of a Proxmox VM from the generic KVM processor to the actual Intel CPU, you can either set it to “HOST” or you can specify the codename Intel used for your CPU. In our clients case, they had E5-2650 v2’s which Intel code named IvyBridge… so we needed to set the VM’s CPU’s to be “IvyBridge”
HOST. This setting will pass through the host CPU features to the VM, effectively using the Intel E5 CPU features.We also wanted to get the clients VirtIO Tools (just virtualization drivers for all the devices, like VMware Tools), updated so we downloaded the latest build from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/virtio-win-pkg-scripts-input/?C=M;O=A .
These two changes made a massive improvement in the performance of our clients VM’s and so we expect this will work for you too.
This website uses cookies.