VMware and SQL Server Best Practices.

Update Note (October 2025): This post was originally written in December 2020 and remains technically sound. I’ve updated it with current context about the VMware landscape, refreshed the monitoring tool references, and expanded the snapshot guidance based on what we continue to see in the field. If you’re evaluating alternatives to VMware, check out our companion post on Hyper-V and SQL Server Best Practices.

This series stays deliberately to the point (for a change.) A lot of this information is available all over the place – but I’m sharing it because we’re still bumping into these issues in the wild and I’d rather you find it and fix it yourself and use us for the more fun and challenging issues!

The VMware Landscape in 2025

Let’s address the elephant in the room: Broadcom acquired VMware in late 2023, and the subsequent licensing changes, price increases, and shift to subscription models have caused a lot of organizations to reevaluate their virtualization strategies. We’re seeing more clients explore Hyper-V, move workloads to cloud platforms, or in some cases, return to bare metal for their most demanding SQL Server instances. We love all of those choices for the right environments, but we love bare metal still for the right workloads – and with Andy Kelly on the team – we have someone who loves to geek out on all the nuances there now.

That said, VMware remains a solid, enterprise-grade virtualization platform. If you’re staying with VMware or managing existing VMware infrastructure, these best practices will help you get the most out of your SQL Server deployments.

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 up 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. Leave the OS partition where it is on the LSI SAS (trust me!)

This VMware KB article talks about how. It’s fairly easy. Requires a power down. Leave the C:\ drive alone – no need to move it.

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: Keep the LSI SAS for the C:\ drive; add 3 more PVSCSI and spread your workload across those controllers.

Sockets and Cores on VMware for SQL Server: What difference does the ratio make?

We see folks having some issues related to 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.

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: Even in 2025, 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 the original 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 – nothign else – and if you want more guest using more RAM than the 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
• As of 2025, aim for hardware version 19 or 20 (ESXi 7.0 and 8.0)
• 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. And this Best Practices white paper from them is a solid start, too.

The Virtualization Decision in 2025

Look, I get it. The Broadcom situation has a lot of 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)

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.