VMware’s conservative guidance about overcommitting your pCPU:vCPU ratio for Monster virtual machines is simple – don’t do it.


If you have a quad socket, 8 core host, this means you have 32 cores, or 64 SMT threads, which vSphere sees as potential logical CPUs. The actual largest monster virtual machine we’d recommend you create is 32 vCPUs for that host.

Why is that?

It is assumed you’ve assigned all those vCPUs because not only are they required by the application, but also that they will be highly utilized.

SMT enables two threads to run simultaneously on a processors core, but since they still share the execution resources of a single core, it does not provide the same throughput as two independent processors cores.

So with that in mind, if you were to assign additional vCPUs, say increase the configuration from 32 vCPU to 64 vCPUs, you are now going to be sharing processor execution resources. This means that while you may see an increase in overall performance, the benefit of using Hyper-Threading SMT technology is measured typically somewhere between 10-15% – not double.

It is this misunderstanding that is often at the root of past performance issues and why this conservative guidance has been adopted. It makes for an easy rule of thumb.

Note: This does not mean you cannot oversubscribe the pCPUs on a host, like we’re all doing today with massive consolidation ratios. It is meant as guidance to not over subscribe a single Monster virtual machine. Incidentally, your consolidation ratios will typically drop when using Monster virtual machines, and that’s okay, as these configurations will be consuming many times the resources of your smaller workloads.

That said, there are times when this oversubscribed configuration can be beneficial.


  • You want massive parallelism. Some applications (Ex: Mapreduce) would rather have access to more threads than a smaller count of faster threads.
  • Your application can use these additional threads and you want to squeeze every last cycle out of your host. I commonly refer to this as benchmarking 😉

Monster virtual machines should not be feared, but they do need to be created responsibly and with knowledge of the hosting infrastructure, to offer maximum performance and meet your businesses KPIs.

About the Author

Mark Achtemichuk

Mark Achtemichuk currently works as a Staff Engineer within VMware’s R&D Operations and Central Services Performance team, focusing on education, benchmarking, collaterals and performance architectures.  He has also held various performance focused field, specialist and technical marketing positions within VMware over the last 7 years.  Mark is recognized as an industry expert and holds a VMware Certified Design Expert (VCDX#50) certification, one of less than 250 worldwide. He has worked on engagements with Fortune 50 companies, served as technical editor for many books and publications and is a sought after speaker at numerous industry events.  Mark is a blogger and has been recognized as a VMware vExpert from 2013 to 2016.  He is active on Twitter at @vmMarkA where he shares his knowledge of performance with the virtualization community. His experience and expertise from infrastructure to application helps customers ensure that performance is no longer a barrier, perceived or real, to virtualizing and operating an organization's software defined assets.