VMware vSphere is licensed on a per cpu socket basis with differing versions available. Each physical CPU socket can contain multiple CPU cores.

Assuming the CPU core count falls within the current revision of the VMware Multicore Pricing and Licensing policy and the relevant vSphere license, then only one license is needed per socket.

The multicore policy is up to six cores per processor which is also known as hexacore processors. The VMware Multicore Pricing and Licensing Policy page also contains the following text :

"Does this policy apply to all future multi-core systems? In other words, what happens when 8-core chips are available?
This policy applies only to dual-, quad- and hexa-core processors. VMware will revisit its licensing policies as x86 processors with a greater number of cores become available."

VMware has already documented the requirements and maximum core numbers in the different versions of vSphere in the related vSphere licensing document.

The maximum cores for the different versions are :

vSphere Standard - 6 core maximum per physical socket
vSphere Advanced - 12 core maximum per physical socket
vSphere Enterprise - 6 core maximum per physical socket
vSphere Enterprise Plus - 12 core maximum per physical socket

VMware's current policy and tightening of the core restrictions in the different versions of vSphere is a direct representation of how powerful CPU processing power has become. There have been astonishing performance results from Nehalem and reports from the field of customers downsizing the amount of VMware Licensing they have because they have hardware refreshed and do not require as many physical CPU's. This is due to the more powerful CPU's and larger memory limitations allowing much higher consolidation ratio's.

While browsing the internet tonight, I stumled across a very lengthy article @ http://www.realtime-windowsserver.com/virtualization/2009/04/how_to_correctly_explain_the_a_1.htm
The core focus of this article was to profess Hyper-V's Efficiency over ESX.

This article was written in response to a well known site administrator and readers comment.

"Many seem to believe that Hyper-V is just Virtual Server 2008. However, I think the main problem is the term "bare metal". What does it really mean? As far as I know any kind of hardware visualization software depends on some kind of underlying operating system. ESX depends on a modified version of Red Hat Linux. But there seems to be a difference in the way Hyper-V and ESX depend on the underlying OS. "

In particular the "ESX depends on a modified version of Red Hat Linux" concerned me greatly, not because it was only incorrect but it was probably one of the only things that was not addressed in the lengthy response. Thankfully a HUGE amount of readers identified this and placed numerous comments in the pages below including someone claiming to be a VMware employee (Randy Robertson). This person stated :

"This is mostly true. With ESX, Redhat is NOT a critical component of the system. No VM I/O goes through the Redhat Console OS. With Hyper-V ALL guest I/O goes through the parent partition. What that means is that if the parent parition gets hacked, not only can your all of your VMs crash, the parent partition could arbitrarily snoop/rewrite any guest I/O such as network traffic. All of your guest OS's are as weak from a stability and security standpoint as the parent partition. To that extend that parent partition _is_ the hypervisor, since the hypervisor by itself will not function.

With ESXi, not only does ESX not depend on a Redhat Console OS for management, there is no Redhat console OS altogether. The Busybox environment is NOT a smaller Linux environment, it is a native ESX environment. With ESXi there literally is NO Linux kernel present anywhere on the system.

ESX does run drivers in the hypervisor directly, but there is no practical difference between this and the Hyper-V approach since a crash in Hyper-V driver in the parent partition DOES bring down the entire host. VMware does extensive QA on certified HCL parts to avoid buggy drivers bringing down the entire platform as might happen if you were to take advantage of the support for odd-ball devices on Hyper-V.

-- VMware employee"

 I ran across another couple of interesting snippets from the main page that were definately worth calling out, feel free to trackback to the original site and post your own comments.

"Hyper-V is considered "microkernalized" because its drivers are all installed into its administrative OS and not into the hypervisor itself. For that reason, Hyper-V's hypervisor is only around 260K in size as compared to ESX's 32M. I usually joke with people at this point that, "with a hypervisor of this size, we're talking about Atari 2600-type coding here. It is extremely small, extremely optimized. The smaller the hypervisor, the faster it can be due to code optimizations, the more secure it can be due to fewer interface endpoints and sheer code itself, which equals what amounts to a more bombproof solution."

"ESX's hypervisor is also extremely small and extremely optimized, but there's simply more to it. It is considered "monolithic" because all of its device drivers exist within its hypervisor."

The interesting thing here is that the comparison made is not based on vSphere which is now the industry benchmark, so it must be a moot point. Definately fun watching the chatter though.