Broadcom just published updated technical guidance for SQL Servers running on VMware, and it’s bundled with the VCF documentation, which includes vSphere. (You can get that 90-page PDF here.) VCF is the Broadcom bundled platform that includes vSphere, vSAN, and NSX.
Below are some of the best practices we work with our clients’ sysadmins to optimize SQL Server success.
Broadcom obviously isn’t just changing around their documentation, but their licensing, so if you’re evaluating alternatives to VMware, check out our companion post on Hyper-V and SQL Server Best Practices. Hyper-V 100% can and does serve SQL Server workloads well. The jury is still out in my mind on Nutanix AHV if you really care about I/O performance based on the experiences we’ve seen, and we are working with a few clients experimenting with open-source virtualization platforms while we slowly hold our breath. But you are here for the SQL Server and VMware best practices so on with the show.
VMware and SQL Server Best Practices
I’ve lost track of the number of times I’ve seen violations of what we’re listing below. And at Straight Path, I don’t just mean we’ve seen the “findings” – but we’ve seen them, we’ve worked with our clients to fix them, and we’ve seen, sometimes significant, performance improvements.
Using the PVSCSI Controllers (… and More than one.)
Want to improve IO performance on your SQL Server VM and reduce CPU overhead?
If you are presenting your storage through data stores to VMDKs and you accepted a standard configuration, you probably have one SCSI controller for your VMs – the LSI SAS controller.
You will normally see both an improvement in IO performance AND a reduction in CPU hit by switching over to the PVSCSI controllers. We’re talking 10-15% improvement from this change alone in many cases.
If you’ve created separate VMDKs for OS/Data/Logs/TempDB/Binaries it would be a good idea to consider adding 2 PVSCSI adapters and splitting the Data/Logs/TempDB at least to them. If you are building a new VM – just use only PVSCSI and move the OS C: drive, your D: drive for the SQL server binaries, and the drive you put your system databases and miscellaneous to the first, and split the drives evenly among the other 3. You don’t need to have the LSI adapter at all.
This VMware KB article talks about how. It’s fairly easy. Requires a power down. If we are working with a client who already has the one LSI SAS adapter, we typically won’t have them change it but simply add 3 more and move the other files around.
Why this matters: The PVSCSI controller has higher queue depths (256 vs 128 for LSI Logic SAS) and lower CPU overhead. For I/O intensive applications like SQL Server, this translates directly to better throughput and more CPU cycles available for your actual workload.
Recommendation: For new builds, use all four PVSCSI controllers. For existing VMs, add 3 PVSCSI and move your workload drives. No need to mess with the OS drive if it’s already on LSI SAS.
Sockets and Cores on VMware for SQL Server: What difference does the ratio make?
We see folks having issues with Socket counts and core counts. There is one very obvious issue – I’ve lost track of the number of VMs running SQL Server Standard (which I prefer if you can do it!) with 8 cores, but 1 core per socket – meaning you are using 8 sockets – 4 more than SQL Server Standard supports. We’ve helped many clients optimize performance simply by fixing this ratio. Almost like suddenly giving them access to the CPUs they thought they had all along…
There is a fairly comprehensive blog post at VMware, which will go a bit deeper but a few thoughts:
- Don’t exceed the sockets of your host.
- Keep the license limitations in mind. In general, more cores per socket is better – but look at the blog post from VMware for more.
- Align your cores and sockets to the host’s physical NUMA topology.
- Consider memory for NUMA boundaries – if you are using less than half of the RAM on a 2 socket box, CPU is the only concern; if you are exceeding that – then you might as well have your cores spread across 2 sockets even if you don’t strictly need them to align CPUs.
Pro tip: Use sys.dm_os_sys_info and sys.dm_os_memory_nodes inside SQL Server to verify your NUMA configuration is what you expect.
Recommendation: Make sure you try and align to the socket:core ratio on your hosts and remember you don’t have 16 socket boxes. You probably need one or two sockets. Less critical about NUMA because of improvements and changes – but you will be losing CPUs you licensed in Standard.. We see it all.the.time.
Can I have too many cores on my SQL Server VM?
Yes, you can. Co-Stop and Ready Time waits are the arch-enemies of SQL Server performance on a VM. You get this from too many guests on a host with too much CPU allocated. You also get it by allocating more cores than you need. Remember – you are in a virtual world now. You can start smaller and add. Try it! Keep the socket:core ratio from above in mind – but start lower and add. You’ll find it easier to do that than take away once you add. You’ll also find that by reducing the number of cores and running that VM a little “hotter” than maybe you would otherwise, you ask the ESXi host for fewer cores to be ready – which means less waiting on these waits.
You should have a solid VMware monitoring tool. We know a thing or two about VMs here, and we can help clients out – but we aren’t VMware admins – for us, the monitoring capabilities built into SolarWinds SQL Sentry (formerly SentryOne) are PERFECT. We can see noisy neighbors. We can see which hosts are busy. We can see which VMs on a host are consuming most of the CPU/IO/Memory. And we can see when ready time and co-stop waits occur.
Recommendation: Monitor for Co-Stop and Ready time waits. Don’t add “all the cores” because you think you want it and you paid for virtual unlimited licensing. Stick to what you need.
PS – If you are one of those folks who actually does CPU hot-add – it’s no longer supported in SQL Server 2025 by Microsoft – but we didn’t want you doing it well before that change anyway, so knock it off.
Noisy Neighbors – and the wrath they bring your SQL Servers
Virtualization is a powerful tool. And it’s great. But we’ve often seen a SQL Server stacked onto a host with far too many VMs. And we’ve seen the DRS/vMotioning of VMs killing SQL Server performance. Know your neighbors. See what else is on the host. I’m not saying you need 1:1 ratios (though, sometimes you may!) but you shouldn’t have your mission-critical SQL Server as just one of the VMs on a crowded host. Look into the entire estate. Get a trial of SolarWinds SQL Sentry and use the VM monitoring capabilities – and see what your host looks like.
Recommendation: Be a good neighbor – but really talk to your VM admin team – make sure you aren’t sitting on a VM that is moving from host to host all day and make sure your neighbors don’t sit there with the CPU volume blaring all day.
High Performance (Everywhere….)
You need to have your Windows OS running in HIGH PERFORMANCE, not balanced mode (I don’t understand why we still bump into that so much!) But not just that – you should have your BIOS set to that, and you should have your ESXi host set to High Performance. Again – we’ve seen 5-10% performance improvements from this change alone.
Why this still matters: The default “Balanced” power plan can cause CPU throttling and P-state changes that introduce latency. For production SQL Server workloads, you want consistent, predictable performance – not power savings.
Recommendation: Change to high performance mode – at the host – in the BIOS – on the guest. Everywhere. Stay there. SQL server doesn’t usually sustain high CPU – so it’s bursty and balanced is terrible with bursty…
Snapshots: Handle With Care
I need to expand on something I only briefly mentioned in the original post: snapshots are not backups and can seriously impact SQL Server performance.
Here’s what we see all the time:
- Someone takes a snapshot “just in case” before a deployment
- They forget about it
- Days or weeks later, SQL Server performance has mysteriously degraded
- The snapshot has grown to hundreds of GB and is causing I/O bottlenecks
Best practices for snapshots:
- Keep them short-lived (hours, not days or weeks)
- Never use them as a backup strategy
- Monitor snapshot sizes – they grow quickly with SQL Server
- Consider using SQL Server-native backup technologies instead
- If you must use snapshots, plan to remove them as soon as possible
The delta disks created by snapshots introduce additional I/O overhead that compounds over time as the snapshot grows. For write-heavy workloads like SQL Server, this can significantly degrade performance.
We have often chased our tails for “odd performance” situations that can’t be explained and finally a VM admin says “all that was happening was some snapshot maintenance…” OUCH.
Recommendation: First off – don’t trust us for VMware snapshot advice – then make sure your VM team has a proper resource for that. Be suspicious of snapshots on performance – and take native backups in SQL if you can on a side note.
Modern Storage Considerations
Since our original VMware post, NVMe storage has become much more common in virtualized environments. If you’re using NVMe-backed datastores:
- The performance difference between PVSCSI and NVMe controllers is minimal
- PVSCSI remains the recommended choice for compatibility and maturity
- Ensure your VMware version supports NVMe correctly (ESXi 6.5+)
- Don’t assume NVMe solves all performance problems – configuration still matters
Memory Management
While the original post focused on CPU and storage, let’s be explicit about memory:
- Avoid memory overcommitment for production SQL Server VMs
- Use memory reservations to guarantee resources for critical SQL Server instances
- Transparent Page Sharing (TPS) is disabled by default in modern ESXi versions, which is actually fine for SQL Server
- Monitor memory ballooning – if you see it on SQL Server VMs, you’ve overcommitted
Recommendation: Overcommit a little on CPU and monitor and make sure you aren’t being killed as per above – but do not overcommit on the memory your SQL Server uses. It’s for SQL – nothing else – and if you want more guests using more RAM than the host will allow – put it somewhere else.
Network Considerations
For SQL Server VMs, especially those handling significant network traffic:
- Use VMXNET3 network adapters (paravirtualized, better performance than E1000)
- Enable Receive Side Scaling (RSS) for better network throughput
- Consider Network I/O Control (NIOC) for QoS if you have multiple workloads competing for bandwidth
- For Always On Availability Groups, ensure your network is properly configured for low latency
Hardware Version and VMware Tools
Keep these current! Seriously.
- Modern VMware Tools include performance improvements and bug fixes
- Hardware version updates enable access to newer VM features
- Aim for the latest hardware version
- Test in non-production first, but don’t let your VMs languish on ancient hardware versions
Some closing thoughts….
There are many more considerations. HA/DR with SQL Server technology vs. VMware HA. Advanced storage features. DRS rules and affinity settings. But just following the tips here – we’ve seen a 10-15% improvement from PVSCSI alone, 5-10% from Power Settings alone, 5-10% from right-sizing (lowering!) core counts or fixing Sockets:Cores – that’s a lot of performance optimization you can do right now without spending a dime on SQL Server consultants like us. (We’re happy to help. But we’re happy for you to handle these low hanging fruit items first yourself too!)
So. That’s what I wish you knew about VMware and SQL Server performance. VMware has some great materials too. I’ve linked some above.
The Virtualization Decision in 2026
Look, I get it. The Broadcom situation has many folks reconsidering their virtualization strategy. We’re seeing organizations:
- Move to Hyper-V for cost savings
- Look to IaaS options in the cloud
- Shift workloads to Azure SQL or AWS RDS
- Return to bare metal for their most demanding instances
- Negotiate hard with Broadcom on licensing (with mixed results)
- Consider open source options at your own risk.
- Consider hyperconverged platforms like Nutanix AHV at potential risk to performance (or cost if you get roped in and then have to buy more to get the performance you expected)
Whatever path you choose, the fundamentals remain: SQL Server needs predictable resources, proper configuration, and monitoring. Whether that’s on VMware, Hyper-V, cloud platforms, or bare metal, these principles translate.
If you need help navigating the virtualization landscape, optimizing your SQL Server performance, or planning a migration strategy, we’re here to help. We’ve been working with virtualized SQL Server for over a decade, and we’ve seen it all.
And as always, if you’re experiencing performance issues you can’t quite pin down, drop us a line. Sometimes it takes an outside perspective to spot what’s been hiding in plain sight. And if it’s a quick e-mail – we’re not looking to make money off of every interaction – happy to point you in a direction.
This post covers virtualization-specific best practices, but we’ve put together a comprehensive SQL Server Best Practices Guide covering everything from configuration to security to maintenance.