This normally does not matter because guest operating systems treat cores as CPUs anyway.  However, there is one significant area that is affected — licensing.  Some operating systems and applications are licensed by physical CPU, regardless of the core count.  If this license is enforced only by a legal agreement, and not by technology, then there is still no problem — configure a four vCPU VM on a system with a quad-core processor and you are in the clear.

The issue arises when software enforces the CPU socket limitation.  One good example of this is an operating system like Windows XP, which supports a maximum of two sockets — there is no way to use four cores if each is presented as a socket even though such an action would still be allowed within the license agreement.

To address this, vSphere 4 introduced a new undocumented VM configuration option called cpuid.coresPerSocket.

If you have experimented with the feature — Duncan Epping already wrote about it a while back — you may have wondered if there is a method to see how many cores and sockets a Windows system has.  After all, Device Manager simply shows each core as a CPU.

One of the more recent Sysinternals tools from Mark Russinovich does that very thing.

Acquiring Sysinternals, and gaining Mark Russinovich, was an exceptionally wise move by Microsoft.  So far, so good — knock on wood — Microsoft has not done anything ridiculous like restricting the tools to be part of a Software Assurance (SA) incentive.

The Sysinternals utility is called Coreinfo.  In these examples I am using it with two flags to show cores and sockets:

coreinfo -c -s

Here is a default VMware ESX 4 VM with 8 vCPUs:

After changing cpuid.coresPerSocket to 8, like so:

The guest OS sees a single socket, 8-core VM:

Setting the value to 4 divides the 8 cores into two sockets like this:

That last setting is the most legitimate for licensing purposes, as the underlying hardware here is a dual quad-core.

Please remember that this feature is currently not supported by VMware GSS.  If you need to use it in production, please contact your VMware account team so that your use case can be taken into account when planning future releases.

Related posts:

1. New VMware ESXi Management Kit
2. VM Resource Management: Hyper-V versus SCVMM
3. Easily view guest IP addresses with vSphere Client
4. Let them eat cake!