Although it's a simple matter to provision virtual processor resources to a VM, there's sometimes a question of just how many vCPUs are appropriate. The answer is that it depends primarily on the application itself and its computing requirements.
A VM running most everyday workloads will function just fine with a single vCPU. In fact, most common workloads, such as a domain name system server, don't need the full compute capacity of a typical enterprise-class CPU core -- it's this reality of unused or idle time that makes it possible for a CPU to share its functionality with a second instruction pipeline, which is known as hyper-threading.
However, it's certainly possible to provision more than one vCPU to a VM. This might be entirely appropriate when the workload is more demanding, such as a database or email server. In most cases, two or four vCPUs should handle the most daunting workloads, but hypervisors, like VMware ESXi 6.0 and later, can provision up to 128 vCPUs to a VM.
The trick is to assign enough virtual processor resources to meet the workload's computing requirements but not so many vCPUs that valuable computing resources are wasted. As a rule, assign vCPUs as physical CPUs based on the system requirements of the workload. For example, if an application recommends a four-CPU server, allocate four vCPUs for the VM. That's often a good place to start.
Be careful assigning vCPUs from the same physical CPU core. Remember that hyper-threading provides a second instruction pipeline, but it shares the CPU's internal subsystems. It doesn't double performance, so even though the hyper-threaded CPU might look like two separate CPUs from a logical perspective, it doesn't mean you have two full-speed CPUs available. A workload demanding enough to require multiple CPUs might benefit from multiple CPUs on different cores.
For example, consider a server with a two-core hyper-threaded CPU. This yields four vCPUs, which would be noted as CPU 0 and CPU 1 on the first core and CPU 2 and CPU 3 on the second core. Now, consider a VM and workload that requires two processors. If CPU 0 and CPU 1 are provisioned for that VM, those two vCPUs actually share the same physical core, and the resulting performance might be inadequate to operate the workload properly. Rather than provisioning CPU 0 and CPU 1 on the same core, try provisioning CPU 0 and CPU 2, which would invoke vCPUs from two different physical cores. The remaining vCPUs -- CPU 1 and CPU 3 in this example -- could be allocated to light workloads or even left unused. Administrators often use CPU affinity and anti-affinity rules to stipulate what CPUs a VM should and shouldn't use.
Fortunately, the number of virtual processor resources allocated to a VM can be changed without destroying and recreating the VM. Administrators can change the number of vCPUs assigned to a VM while the VM is powered off. However, more recent hot plug capabilities in a hypervisor, if enabled, can allow administrators to increase the number of vCPUs while the VM and workload are actually running.
Learn about application resource management
Ensure workload resiliency with these strategies
Deploy applications to VMs or containers
Dig Deeper on Virtual machine performance management
Related Q&A from Stephen J. Bigelow
Learn how load balancing in the cloud differs from a traditional network traffic distribution, and explore services available from AWS, Google and ... Continue Reading
Access management is critical to securing the cloud. Understand the differences between AWS IAM roles and users to properly restrict access to AWS ... Continue Reading
Containers have rapidly come into focus as a popular option for deploying applications, but they have limitations and are fundamentally different ... Continue Reading