RGE, if your question is that there is a limit to the number of vCPUs that can be assigned to a particular VM, yes that's correct. There is an absolute limit even if you buy the most expensive version of ESXi, and there's an artificial limit placed on some of the lower end offerings. It's also true that if you are going to use VMWare and your workload supports being divided up among several operating system instances (i.e. multiple VMs), rather than multiple processes within the same operating system instance, if you need more vCPUs than you can assign to a single VM, provided you have enough extra memory to handle the additional memory usage that splitting the workload into multiple VMs may require, that you may get better performance.
Some of the rules of thumb I use are these:
1). If the total number of vCPUs assigned to all running VMs is equal or less than the number of cores on the box minus 1, you will never have CPU problems (the minus 1 is there because ESXi itself needs CPU, and if you are doing something like deleting a snapshot or taking a backup, it can use quite a bit).
2). If a single VM isn't assigned more than 1/4 of the vCPUs on the box it usually won't have contention problems with other VMs unless the workloads of most of the VMs on the box are CPU bound. This only works though if you only assign one VM a number of VCPUs equal to 1/4 of the box, and the others aren't assigned more than 1/6 or 1/8 of the box. The idea is that the hypervisor's time slicing algorythim works more smoothly if most of the VMs it's time slicing are using a smaller percentage of the resources each (i.e. more VMs using fewer vCPUs time slice better than fewer VMs using more vCPUs each). Of course the best time slicing is when most of the VMs are using only one vCPU.
3). If one VM is significantly more important than the others (i.e. it has to run and give good response time all the time even if that occasionally means that the other VMs suffer for short periods of time) you can use the system affinity settings to block the other VMs from using one or more of the vCPUs so that the important workload always has an advantage. If you have enough cores available you can even isolate the important VM completely by forcing it on to specific cores for all the vcpus assigned to it and preventing the other VMs from ever using those cores. That ensures that the important VM is guarenteed to run immediately whenever it has work to do, and can never be slowed down CPU wise by the other VMs. When I do this I always use the highest number vcores for the isolation as my informal testing seems to show that the ESXi hypervisor prefers using the lowest vcore number it can find when it has work to do, and you can't prevent the hypervisor itself from using certain cores as far as I know.
