[EN] The Importance of vCPU and Cores per Socket Configuration in VMware Environments

When planning virtual machine performance, most administrators usually focus only on the total number of vCPUs assigned to a VM. If an application is slow or needs more processing power, the first reaction is often to increase the VM’s CPU count.

However, in VMware environments, performance is not determined only by how many vCPUs are assigned. Another critical factor is how those vCPUs are presented to the virtual machine, especially in terms of virtual sockets and cores per socket.

This becomes even more important on modern physical servers with multiple processors and many CPU cores. These systems are built on a memory and processor architecture called NUMA, which directly affects how efficiently virtual machines access CPU and memory resources.

A VM designed in line with the physical NUMA architecture can achieve:

• Lower memory access latency
• More efficient CPU utilization
• Better application performance
• More predictable workload behavior

On the other hand, an incorrect socket/core layout or a VM topology that does not match the physical NUMA structure can cause unexpected performance issues, especially on systems such as SQL Server, Exchange Server, ERP platforms, database servers, and high-performance application servers.

For this reason, virtual machine design should not only answer the question:

“How many vCPUs should we assign?”

It should also answer:

“How should these vCPUs be presented to the VM?”

What Is NUMA?

NUMA stands for Non-Uniform Memory Access.

In simple terms, NUMA is an architecture used in multi-processor systems where each physical CPU socket has its own local memory area. A processor can access its own local memory faster than memory connected to another processor socket.

For example, let’s consider the physical server structure shown in the image:

• 2 physical CPU sockets
• 10 physical cores per socket
• 20 physical cores in total
• 40 logical processors with Hyper-Threading
• 256 GB total RAM
• 128 GB RAM per CPU socket

In this architecture, each physical CPU socket can be considered a separate NUMA node.

So, the first CPU socket has its own local 128 GB memory area, and the second CPU socket has its own separate 128 GB memory area.

When a CPU accesses memory that is local to its own socket, latency is lower. However, if it needs to access memory attached to the other CPU socket, the operation becomes more expensive and slower.

This is where NUMA awareness becomes important.

What Is vNUMA in VMware?

In VMware environments, the virtual representation of physical NUMA architecture is called vNUMA, or Virtual NUMA.

vNUMA allows large virtual machines to understand and use the underlying physical NUMA topology more efficiently. ESXi evaluates the number of vCPUs and the amount of memory assigned to a VM and tries to place the VM in the most suitable physical NUMA layout.

For example, if a physical host has:

• 10 physical cores per NUMA node
• 128 GB RAM per NUMA node

then a VM with 8 vCPUs and 64 GB RAM can usually fit inside a single NUMA node. This is generally efficient because CPU and memory access remain local.

However, if a VM is configured with 16 vCPUs and 160 GB RAM, it can no longer fit inside a single NUMA node. In this case, the VM may need to span multiple NUMA nodes.

This is not necessarily wrong, but it must be planned carefully.

vCPU Count Alone Is Not Enough

Assigning 8 vCPUs or 16 vCPUs to a virtual machine is not simply a matter of “more CPU equals more performance.”

As the number of vCPUs increases, ESXi must schedule more virtual CPUs on physical CPU resources. This can become more complex, especially when the VM crosses physical NUMA boundaries.

For small VMs, this is usually not a major issue. However, for large and performance-sensitive workloads such as:

• SQL Server
• Exchange Server
• ERP systems
• Large application servers
• RDS servers
• Database workloads
• Analytics platforms
• High-transaction systems

CPU topology can make a significant difference.

An incorrectly configured VM may experience:

• Increased CPU Ready time
• Application slowdowns
• Higher memory access latency
• Inefficient workload distribution across NUMA nodes
• Lower database performance
• Poor scaling even after adding more CPU
• Unpredictable performance during peak usage

That is why the correct approach is not only to assign more vCPU, but to assign it in a way that matches the physical architecture.

Technical Interpretation of the Example Image

The image shows a physical host with the following structure:

• Intel processor platform
• 2 physical CPU sockets
• 10 cores per socket
• 40 logical processors
• 256 GB total RAM
• 128 GB RAM per socket

In this design, each physical NUMA node has approximately:

• 10 physical CPU cores
• 128 GB RAM

When creating a VM on this host, it is generally better to keep the VM inside a single physical NUMA node whenever possible.

For example, the following configurations can remain within a single NUMA node:

vCPU	Recommended VM Configuration	vNUMA Nodes
1	1 socket x 1 core	1
2	1 socket x 2 cores	1
4	1 socket x 4 cores	1
8	1 socket x 8 cores	1
10	1 socket x 10 cores	1

Since these configurations do not exceed the 10-core boundary of a single physical NUMA node, they are generally more efficient.

However, once the VM requires more than 10 vCPUs, it can no longer fit into a single NUMA node. In that case, the VM should be distributed across two NUMA nodes in a balanced way.

Examples of better-balanced configurations are:

vCPU	Recommended VM Configuration	vNUMA Nodes
12	2 sockets x 6 cores	2
14	2 sockets x 7 cores	2
16	2 sockets x 8 cores	2
18	2 sockets x 9 cores	2
20	2 sockets x 10 cores	2

In contrast, values such as 11, 13, 15, 17, and 19 vCPUs are shown as sub-optimal in the image. The reason is that these values cannot be divided evenly across the two NUMA nodes.

This may lead to an unbalanced virtual CPU topology and less efficient resource usage.

What Does Cores per Socket Do?

In VMware, the Cores per Socket setting determines how the assigned vCPUs are presented to the guest operating system.

For example, a VM with 8 vCPUs can be presented in different ways:

• 8 sockets x 1 core
• 4 sockets x 2 cores
• 2 sockets x 4 cores
• 1 socket x 8 cores

In all examples, the total vCPU count is still 8. However, the guest operating system sees the CPU topology differently.

This matters for several reasons:

• How the operating system detects CPU topology
• How NUMA-aware applications behave
• Software licensing models
• SQL Server socket/core behavior
• Performance monitoring and troubleshooting
• Application thread scheduling

In modern vSphere versions, Cores per Socket is not always the main control mechanism for vNUMA topology as it was in older versions. However, it can still affect how the guest OS and applications understand the virtual CPU layout.

That means it should not be changed randomly.

Old Approach vs. Modern vSphere Behavior

In older VMware versions, the Cores per Socket setting had a stronger relationship with vNUMA presentation. Administrators often manually adjusted socket/core values to influence NUMA behavior.

In newer vSphere versions, ESXi has improved automatic CPU topology and vNUMA placement mechanisms. Features such as automatic topology assignment can help VMware present a more suitable CPU layout based on the physical host architecture.

However, this does not mean administrators should ignore CPU topology completely.

The following items should still be evaluated together:

• ESXi version
• VM hardware version
• Physical CPU socket count
• Physical cores per socket
• NUMA node size
• VM vCPU count
• VM memory size
• CPU Hot Add status
• Application requirements
• Licensing model
• Guest OS behavior

The best configuration may vary depending on the workload and environment.

Be Careful with CPU Hot Add

VMware provides a feature called CPU Hot Add, which allows administrators to add CPU resources to a VM while it is running.

Although this is operationally convenient, it is not always the best option for performance-sensitive workloads.

In some VMware versions, enabling CPU Hot Add could affect vNUMA presentation or prevent the guest OS from seeing the optimal NUMA topology. In newer versions, this behavior has improved, but it should still be reviewed carefully.

For critical systems such as SQL Server, Exchange Server, large databases, or heavy application servers, CPU Hot Add should not be enabled by default without understanding its impact.

Before enabling it, administrators should ask:

• Does the application really need online CPU expansion?
• Does the ESXi version support proper vNUMA behavior with CPU Hot Add?
• Is this VM performance-sensitive?
• Is the guest OS NUMA-aware?
• Is the application NUMA-aware?

Operational flexibility should not come at the cost of performance stability.

Memory Size Is Also Critical in NUMA Design

NUMA planning is not only about CPU count. Memory size is just as important.

In the example shown in the image, each physical socket has 128 GB RAM. This means one NUMA node contains 128 GB of local memory.

A VM with:

• 8 vCPUs
• 96 GB RAM

can fit inside a single NUMA node.

However, a VM with:

• 8 vCPUs
• 160 GB RAM

cannot fit entirely inside one NUMA node because the memory requirement exceeds the 128 GB local memory boundary.

Even though the CPU count fits within one NUMA node, the memory does not. As a result, the VM may need to access memory from another NUMA node, which can increase latency.

This is especially important for memory-intensive workloads such as:

• SQL Server
• Exchange Server
• Large JVM applications
• In-memory databases
• Analytics workloads
• Large enterprise applications

For these workloads, both CPU and memory must be evaluated together.

Why Is This More Important for SQL Server and Exchange?

Applications such as SQL Server are NUMA-aware. This means they can detect the NUMA topology presented by the operating system and optimize workload scheduling accordingly.

If the VM’s vNUMA topology matches the physical NUMA architecture properly, SQL Server can use CPU and memory resources more efficiently.

However, if the VM is configured with an unsuitable socket/core layout or an unbalanced vNUMA topology, SQL Server may not use resources optimally.

This can result in:

• Poor query performance
• Increased wait times
• Inefficient memory usage
• Uneven CPU load
• Lower transaction throughput
• Performance drops during peak hours

Exchange Server, ERP systems, RDS environments, and large application servers can also be affected by similar CPU and memory topology issues.

Hyper-Threading Can Be Misleading

The example host has 40 logical processors. However, this number includes Hyper-Threading.

Hyper-Threading does not mean the server has 40 full physical cores. It means each physical core can process more than one thread.

In this example:

• Physical cores: 20
• Logical processors: 40
• Physical cores per socket: 10
• Logical processors per socket: 20

When planning NUMA and vCPU sizing, the physical core count is usually more important than the logical processor count.

A common mistake is assuming that because a socket has 20 logical processors, a single NUMA node can efficiently host a 20 vCPU VM. In reality, the socket has only 10 physical cores.

That is why the single NUMA node boundary in this example should be evaluated based on 10 physical cores, not 20 logical processors.

Example of an Incorrect Configuration

Assume the physical host has:

• 2 sockets
• 10 cores per socket
• 128 GB RAM per socket

Now assume a VM is configured with:

• 15 vCPUs
• 96 GB RAM

The memory size can fit within one NUMA node, but the CPU count cannot. Since 15 vCPUs exceed the 10-core boundary, the VM must span multiple NUMA nodes.

However, 15 cannot be evenly divided across two NUMA nodes. This may create an unbalanced topology.

In this case, the administrator should evaluate questions such as:

• Does the VM really need 15 vCPUs?
• Would 14 vCPUs be enough?
• Would 16 vCPUs provide a more balanced design?
• What does CPU Ready look like?
• Is CPU usage actually high?
• Is the application NUMA-aware?
• Does the guest OS see the correct topology?
• Is the workload scaling properly?

The goal is not always to give more CPU. The goal is to provide CPU in the most efficient architecture.

General Best Practices for vCPU and Cores per Socket Planning

1. Understand the Physical Host Architecture

Before designing large VMs, you should know:

• Number of physical CPU sockets
• Number of physical cores per socket
• Number of NUMA nodes
• RAM per NUMA node
• Hyper-Threading status
• ESXi version
• CPU generation

Without this information, proper VM sizing is not possible.

2. Keep VMs Inside a Single NUMA Node When Possible

For small and medium-sized workloads, keeping the VM within a single NUMA node usually provides better performance.

In the example architecture, a VM with up to 10 vCPUs and up to 128 GB RAM can generally stay within one NUMA node.

This can reduce memory access latency and improve consistency.

3. Use Balanced NUMA Distribution for Large VMs

If a VM must exceed the size of a single NUMA node, it should be distributed evenly across multiple NUMA nodes.

For example, on a host with 10 cores per socket:

• 12 vCPU = 2 x 6
• 14 vCPU = 2 x 7
• 16 vCPU = 2 x 8
• 18 vCPU = 2 x 9
• 20 vCPU = 2 x 10

These configurations are more balanced than odd values such as 11, 13, 15, 17, or 19.

4. Be Careful with High Odd vCPU Counts

Odd vCPU values above a single NUMA node boundary can create unbalanced CPU distribution.

For example, if a host has 10 cores per NUMA node, values such as:

• 11 vCPU
• 13 vCPU
• 15 vCPU
• 17 vCPU
• 19 vCPU

may not be ideal.

This does not mean they will always fail or always perform badly, but they should be reviewed carefully.

5. Do Not Change Cores per Socket Randomly

Cores per Socket can affect how the guest OS and applications see CPU topology.

Changing it without understanding the workload can cause:

• Licensing issues
• Incorrect CPU topology presentation
• Application-level performance problems
• Troubleshooting confusion

For modern vSphere environments, it is usually better to rely on automatic topology behavior unless there is a specific reason to override it.

6. Review CPU Hot Add Before Enabling It

CPU Hot Add is useful, but not always ideal for large or performance-sensitive VMs.

For critical workloads, evaluate its impact before enabling it.

7. Monitor Performance with the Right Metrics

Do not evaluate performance only by looking at CPU usage.

You should also check:

• CPU Ready
• CPU Co-Stop
• CPU Usage
• Memory latency
• NUMA locality
• Guest OS CPU topology
• Application-level performance counters
• Database wait statistics
• ESXi host contention

A VM may show low CPU usage but still suffer from scheduling or NUMA-related performance issues.

Performance Optimization Is Not Just Adding More Resources

One of the most common mistakes in virtual environments is assigning more CPU or RAM whenever a VM has a performance problem.

In some cases, this can actually make the problem worse.

For example, a VM running efficiently with 8 vCPUs inside a single NUMA node may become less efficient after being increased to 12 or 16 vCPUs if the NUMA topology is not planned correctly.

More resources do not always mean better performance.

A better approach is to ask:

• Is the VM really CPU-bound?
• Are the assigned vCPUs being used efficiently?
• Is CPU Ready high?
• Is the VM crossing NUMA boundaries?
• Is memory access local or remote?
• Does the guest OS see the correct NUMA topology?
• Is the application NUMA-aware?
• Is the VM hardware version suitable?
• Is the ESXi version using automatic topology correctly?

In many cases, the correct solution is not to add more CPU, but to present the existing CPU resources in a better architecture.

In VMware environments, vCPU and Cores per Socket configuration plays an important role in virtual machine performance.

The total number of vCPUs is important, but it is not the only factor. How those vCPUs are presented to the virtual machine, how they align with the physical NUMA architecture, and how the guest operating system and applications interpret the topology can directly affect performance.

This is especially important for workloads such as:

• SQL Server
• Exchange Server
• ERP systems
• Large databases
• Application servers
• RDS environments
• High-performance workloads

Incorrect CPU topology can cause performance problems even when the VM appears to have enough resources.

For this reason, VM design should focus not only on resource quantity, but also on resource architecture.

In virtualization, real performance optimization is often achieved not by assigning more CPU or RAM, but by delivering those resources in the right topology.