The Broadcom acquisition of VMware pushed licensing costs up across the tech sector, forcing IT leaders and MSPs to explore alternative hypervisors. Alternatives like Proxmox, Hyper-V, Nutanix, HPE Morpheus or moving directly to cloud platforms like Azure are rapidly gaining traction as teams rush to eliminate the crazy spend Broadcom is looking for or their dwindling number of partners are needing to get to afford their partnership tax.
Saving money on licensing makes strategic business sense, but executing a quick “lift and shift” migration of production database servers into an untested virtualization environment creates serious hidden risks. I’m all for a fun rope swing into a river…. But I’m a fan of not being the first one or at least looking around a little bit before leaping… Some recent chats with clients brought this back up, made me rant a bit on a video (below) but here’s the point I’m getting at.
The Return of Virtualization “Gremlins” for our SQL Servers
In the early days of virtualization 15 years ago or whenever those bleeding edge days were, us DBAs spent countless hours chasing transient issues, unexpected I/O bottlenecks, and mysterious storage corruption (“no… SQL can’t be at fault here because this is how it works” conversations were definitely had…) Over the last decade, hypervisors matured to the point where database teams rarely had to worry about underlying host layers. I haven’t fought for an RDM in ages on VMware – though I still push for PVSCI and other best practices and still arm wrestle about the snapshot breaking production performance a bit too much. Most of that is covered in our VMWare Best Practices guide for SQL Server.
With the sudden rush away from VMware, those early-era gremlins are starting to return here and there, and I’m getting a little scared for our clients. Especially when their sysadmins or integration partners sort of move them and then tell us (their DBA teams…) When hosting providers or MSPs take a legacy VM (running Windows Server 2012, 2016, or 2019 with SQL Server whatever version) and wedge it directly into Proxmox or another hypervisor without adjusting underlying drivers, storage caching, or NUMA configurations, problems follow quickly:
- Unexplained Performance Degradation: Storage latencies spike due to unoptimized virtual disk controllers or caching policies.
- Transient Storage Failure & Corruption: Database integrity errors and corruption spikes often align directly with the exact date a VM was migrated. (It was a series of transient checksum errors that brought this post to mind – and until today they dodged the corruption. Thankfully it’s an AG and the other node is good for now – though each node have the checksum errors when either is primary…)
- Configuration Oversights: Default settings on cloud platforms like Azure or open-source hypervisors are rarely tuned for heavy database write workloads.
Why “Lift and Shift” Fails Production Databases
Databases are fundamentally different from standard application servers. SQL Server relies heavily on low storage latency, explicit CPU/memory allocation, consistent disk flush guarantees, and stable driver stacks. (I mean all server types like all of those things, but a database server really really realllllly needs those things)
When an IT team or MSP migrates a database VM using standard default settings:
- Disk Flushing Policies: Some hypervisor caching modes do not honor write-through guarantees, putting transaction logs at risk during power or host events.
- CPU & NUMA Mapping: Default virtual CPU assignments can break NUMA node alignment, severely choking SQL Server memory access speeds.
- Driver Incompatibilities: Legacy guest OS drivers interacting with newer host kernel modules cause unexpected driver-level resets.
Saving $30,000 on VMware licensing provides little value if it leads to an emergency outage that costs double that amount in downtime and consulting fees – I’ll take the hours, sure, but I’d rather the client and their clients keep the peace of mind.
A 4-Step Checklist Before Migrating SQL Server Hypervisors
Before letting an MSP or internal infrastructure team migrate a production database host to Proxmox, Hyper-V, or Azure, verify these four steps:
| Migration Phase | Action Required |
| 1. Database Stakeholder Sign-Off | Involve your DBA team or SQL Server consultants before scheduling host migrations, not after performance drops. Really involve us when the conversation is starting. Let us all talk about the pros and cons. Let us really analyze things. I’ve had so many performance woes from clients who went Hyperconverged because the folks at Nutanix or wherever who sold them said all would be fine… |
| 2. Storage & Caching Validation | Confirm that virtual disk caching settings on the new hypervisor explicitly support enterprise database write patterns (e.g., Direct I/O or Write-Through). Understand the best way to tune the IO for stability and guarantees while meeting the performance you have expected. |
| 3. Non-Production Dry Run | Perform a test restore and full workload stress test on the target hypervisor, running DBCC CHECKDB to confirm data integrity post-migration. Hit the DB with as much load as you can – and run some checkdbs and index maintenance while hitting it with the load – see what shakes out down. |
| 4. Baseline & Monitoring | Capture baseline SQL Server performance metrics (Wait Stats, Disk Latency, Page Life Expectancy) before the move so post-migration anomalies can be immediately identified. |
In addition to those steps (that’s the minimum – and it would save you a lot of extra time with your DBA team or Managed DBA as a Service provider..) really ask if the lift and shift is the best way. If you are migrating, say, a Win 2016 server – maybe it’s time to consider doing a migration and building a clean VM from scratch. How many old machines were P2Vd up to VMware to begin with? You want to roll the dice and do a “V2V” with that now? Taking all of the pain that has been on that server for 8-10 years and gamble that production will be fine?
Proactive Planning Beats Emergency Support
Alternative hypervisors like Proxmox or cloud hosts like Azure can run SQL Server effectively, but only when configured with proper database-first architecture. And the newer the virtualization technology (or at least newer to high end performance databases on Windows) it is, the more care you need to give before going there.
At Straight Path, our goal is always to help organizations avoid emergencies before they happen. If your organization is planning a hypervisor transition, reach out to your database team or outside SQL Server experts to review the migration plan beforehand.