This is a contentious subject. I call out some key information from VMware later and I describe the biggest pitfalls below, but the key takeaway is this...

SQL on VMWare CAN work well IF done properly (but you are probably NOT doing it properly)

CPU

SQL Server and VMware tend to clash around CPU usage because they make very different assumptions about who is in control of scheduling, and those assumptions collide once SQL is running inside a virtual machine.

SQL Server is designed to manage CPU very aggressively. It uses its own scheduler (SQLOS) on top of Windows, assumes that when a worker thread is runnable it will get CPU immediately, and interprets any delay as “CPU pressure”. When SQL sees waits like SOS_SCHEDULER_YIELD or high runnable queue lengths, it assumes the host is genuinely busy and reacts by throttling work, changing query plans, or reporting CPU saturation.

VMware, on the other hand, is also a CPU scheduler. ESXi decides when a VM is allowed to run on physical cores, how long it runs, and when it is paused so another VM can run. From inside the VM, SQL Server has no visibility of this. If ESXi deschedules the VM, SQL just sees time passing with no progress and concludes that CPU is starved, even if the physical host still has capacity.

One of the biggest friction points is CPU Ready time. When a SQL VM wants to run but ESXi can’t immediately schedule it on physical cores, the VM accumulates CPU Ready. SQL interprets this as poor CPU performance, even though Windows shows high idle or moderate utilisation. This is why you can see slow queries and SOS_SCHEDULER_YIELD waits while Task Manager says CPU is only 40–50%.

vCPU sizing makes this worse. SQL generally prefers fewer, faster cores. VMware has to find a free physical core for each vCPU in the VM at the same time. Large vCPU counts increase scheduling complexity and CPU Ready, especially on busy hosts. From SQL’s point of view, “I have 16 CPUs but they’re all slow”, which is often worse than having 8 consistently available CPUs.

NUMA

See (1, p27 on)

SQL is NUMA-aware and tries to keep memory and CPU local to a NUMA node. If the VM’s vNUMA layout doesn’t align with the physical NUMA topology, SQL may think it is optimally placed while ESXi is actually bouncing vCPUs across physical NUMA nodes. This adds latency and can show up as CPU pressure or CXPACKET/CXCONSUMER waits.

Hyperthreading

SQL treats logical CPUs as real schedulable resources. ESXi schedules vCPUs onto physical cores and hyper-threads based on its own fairness rules. Under contention, SQL might be running on sibling hyper-threads and see inconsistent performance even though core-level utilisation looks acceptable from the host.

VMware recommends enabling hyper-threading to improve performance (1, p21).  "VMware recommends enabling Hyper-threading in the BIOS/UEFI so that ESXi can take advantage of this technology. ESXi makes conscious CPU management decisions regarding mapping vCPUs to physical cores, taking Hyper-threading into account. An example is a VM with four virtual CPUs. Each vCPU will be mapped to a different physical core and not to two logical threads that are part of the same physical core."  (1, p25)

VMware also recommend  that for best performance you should start with... "the total number of vCPUs assigned to all the VMs be no more than the total number of physical, not logical, cores available on the ESXi host machine"  (1, p24) until you can identify any potential excess capacity. 

Power Management

SQL assumes relatively stable CPU frequency. If ESXi or the underlying hardware is aggressively saving power, SQL can see slower-than-expected CPU execution and again interpret it as contention. 

vSphere vMotion

"SQL servers can be vmotioned without issues. Depending on the speed your switch handles the ARPs which tell the physical switch where the VM has gone, you could miss connectivity for a short time. This is handled by TCP itself (retransmit) and should never cause you to loose a session to the VM"

"vSphere vMotion greatly enhance manageability of the solution build and should always be considered. For a production deployment testing under load is highly recommended." (my emphahsis)

vSphere High Availability Cluster (HA)

"In case of a hardware failure of an ESXi host, a VM will be restarted on one of the surviving ESXi host in the cluster. Guest OS and SQL Server will experience a non-graceful shutdown and restart similar to a start of the system after power loss. SQL Server databases should be checked before client connections are allowed."

vSphere Fault Tolerance (FT)

"An Identical copy of the primary VM will be created and all CPU instructions will be replicated from primary to secondary. In case of a failure of the primary VM, the secondary will take over with the exact the same state as the primary had before the failure."

CPU Hot Plug

Although this is supported by SQL2008+ (EE only), it is NOT recommended for SQL Server VMs due to the impact it has on the vNUMA capability (1, p25)

Bibliography & References