3 Answers
3

The best explanation I've heard for 'You should only have one vCPU per VM' is as follows:

When a VM wants a portion of processing time, it waits by the sidelines until it can put a lock on n physical CPU's, where n is the number of vCPUs the VM has. If there is only one vCPU within the VM, it only has to wait until one physical CPU is available before it can jump in and get some stuff done. If it has two or more vCPU's, it has to wait until two or more CPU's are simultaneously available before it jumps in and gets on with things (It will not lock one CPU at a time and wait for more to follow it- it has to wait for multiple to be available before it can pounce)

If you have a bunch of single-vCPU VM's thrashing the physical CPU's, and one multiple-vCPU VM wanting to process, it will possibly have to wait for quite some time as the single-vCPU VM's jump in and keep snatching away spare CPU's before the multiple-vCPU box can get a lock on the number of CPU's that it needs.

VM's lock, use and unlock CPU's rapidly, but the above behaviour can cause poor performance of multi-vCPU boxes in certain situations.

I hope that makes sense (There were a lot of CPU and vCPU and VM mentions, I hope I didn't mix anything up)

This is only heresay - my boss attended VMWare training and relayed the above story to me. It has gone from instructor to my boss to me to you, so take it as you will.

This is a great explanation but there is one clarification I would make. vCPU's each map onto what VMware calls a hardware execution context and multi-vCPU systems have to be able to schedule all of their hardware execution contexts concurrently. VMware treats each logical core in a multi-core physical CPU as a hardware execution context rather than the physical CPU\socket, just in case that wasn't clear.
–
HelvickNov 17 '09 at 9:34

This is a good explanantion but it can be put simply by stating multi-vCPU systems have to be able to schedule all of their hardware execution contexts (cpus) concurrently on the same host. If you do not have enough contexts free now they have to be swapped in and out causing performance degradation.
–
Jim BNov 17 '09 at 13:42

You can create n VM's with 4 vCPU's.
The question is if the performance of the vm's will be good.

Best practice is just to add 1 vCPU per VM and add another vCPU if you really need one.
I just have one or two VM's with 4 vCPU's.

Every VM's shares the physical CPU's of the host system. As more vCPU's you add the more time slices a VM get to work on the physical CPU. Normally you don't reserve a physical CPU only for one VM. It's possible but normally not needed.