A query that used to run in two seconds now takes twenty. The execution plan has not changed. The indexes are the same. CPU and...
A query that used to run in two seconds now takes twenty. The execution plan has not changed. The indexes are the same. CPU and memory inside the guest OS look unremarkable. Every SQL-side signal a DBA knows how to read says nothing is wrong, and yet something clearly is.
In a virtualized environment, this is one of the most common and most frustrating investigation dead ends a DBA can hit, because the actual problem is often happening one layer below where SQL Server-only monitoring can see.
SQL Diagnostic Manager for SQL Server, also known as SQL DM, closes that gap by surfacing hypervisor-level metrics, including CPU ready time, memory ballooning, and host-level disk latency, right alongside SQL Server metrics for both VMware and Hyper-V environments. The IDERA Virtual Product Tour of SQL Diagnostic Manager for SQL Server demonstrates this virtualization awareness as part of the broader product walkthrough.
VM and virtualization awareness in SQL Diagnostic Manager for SQL Server surfaces hypervisor-level metrics, including CPU ready time, memory ballooning, and host-level disk latency, alongside SQL Server performance data for both VMware and Hyper-V environments. This helps DBAs distinguish a genuine SQL Server problem from a symptom caused by resource contention at the virtualization host layer.
Virtual Product Tour of SQL Diagnostic Manager for SQL Server
Every SQL Server monitoring tool, including SQL DM, is very good at answering questions inside the SQL layer: which query is slow, what it is waiting on, what its execution plan looks like, and how much CPU and memory the guest OS reports using. In a physical, non-virtualized environment, that is usually enough because the hardware underneath SQL Server is dedicated to it.
In a virtualized environment, that assumption breaks down. The guest OS inside a VM reports what it believes its CPU and memory usage to be, but it has no visibility into what the hypervisor is actually doing with the physical host’s resources on its behalf. It cannot see whether the VM’s CPU requests are being queued behind other VMs on the same host, whether memory the guest thinks it has has been silently reclaimed, or whether the physical storage backing the VM’s virtual disks is under pressure from unrelated workloads sharing the same array.
A monitoring tool that only sees inside the guest is structurally unable to answer those questions, no matter how sophisticated its SQL-layer analysis is.
Most SQL Server monitoring tools miss this entirely. SQL DM’s virtualization awareness brings host-level context into the same view as SQL metrics, specifically:
Individually, any one of these can produce exactly the symptom a DBA is used to diagnosing as a SQL problem: queries that slow down for no visible reason, intermittent timeouts, or general sluggishness that comes and goes without a clear trigger.
Seeing them next to SQL metrics, for the same instance, at the same time, is what turns “I have no idea why this is slow” into a specific, assignable finding.
Consider a reporting query that intermittently takes ten times longer than usual, with no change to the query itself, its indexes, or the data volume it processes. The DBA checks the execution plan, checks for blocking, and checks wait statistics inside SQL Server. Everything inside the SQL layer looks normal for the moments the slowdown occurred.
Hours go into ruling out one SQL-side theory after another, and each dead end makes the eventual explanation feel further away rather than closer.
With host-level visibility available in the same view, the same investigation takes a different shape. CPU ready time for the VM spikes at exactly the moments the query slows down, correlating with a batch job that runs on a neighboring VM sharing the same physical host.
The fix is not a SQL Server change at all. It is a conversation with the infrastructure team about host resource allocation or VM placement. Without host-level visibility, that conversation likely never happens, because nothing on the SQL side ever pointed toward it.
One of the most underrated effects of host-level visibility is what it does to cross-team conversations. Without it, a DBA reporting “I think this might be a VM or host issue” to an infrastructure team is offering a guess, and guesses are easy to deprioritize against a busy infrastructure team’s other work.
With specific host-level data, including CPU ready time at a specific timestamp, a specific ballooning event, or a specific disk latency spike, the same conversation starts from evidence instead of a hunch and gets taken seriously accordingly.
This matters because SQL Server performance and virtualization infrastructure are usually owned by two different teams who do not naturally share monitoring data. Host-level VM awareness inside a SQL-focused tool gives the DBA team a shared, specific vocabulary to use in that conversation, rather than requiring infrastructure-side tooling access they may not have or forcing them to wait for the infrastructure team to independently notice and report the same problem.
Teams getting real value out of host-level VM visibility tend to follow a consistent pattern:
The specific way host-level metrics get collected differs by hypervisor. In a VMware environment, the ESXi hypervisor on each host collects performance statistics and reports them to a central vCenter Server, and SQL DM collects that data from vCenter to display alongside SQL metrics.
In a Hyper-V environment, SQL DM collects the required performance statistics directly from the Hyper-V host server and its virtual machines.
The underlying blind spot is the same across both platforms: SQL-only monitoring misses what is happening at the host layer. Only the collection mechanism differs.
This is worth calling out explicitly because teams sometimes assume virtualization-awareness features are VMware-specific, given VMware’s larger market presence in enterprise environments. Hyper-V environments have exactly the same visibility gap and exactly the same need for host-level metrics next to SQL data.
Host-level, hypervisor-aware visibility is something most SQL Server monitoring tools miss entirely. They monitor the guest OS and SQL Server instance, then treat the underlying host as someone else’s problem. That is a real gap, not a minor one, in any environment where SQL Server workloads share physical hosts with other VMs, which describes most modern virtualized data centers.
For teams evaluating monitoring depth specifically for virtualized SQL Server environments, host-level visibility next to SQL metrics is a concrete, demonstrable difference. It is also one best shown live against a prospect’s own VMware or Hyper-V environment, since the value becomes obvious the first time it explains a symptom that SQL-only monitoring could not. And this is where SQL Diagnostic Manager shines.
Does VM and virtualization awareness require a separate license or add-on?
No. Virtualization monitoring is included in the standard SQL DM license, though it does require connecting SQL DM to your vCenter Server for VMware or Hyper-V host, which is a configuration step rather than a licensing one.
Does this work for both VMware and Hyper-V?
Yes. SQL DM collects host-level metrics from vCenter Server in VMware environments and directly from the Hyper-V host in Hyper-V environments, surfacing both alongside SQL metrics.
What is CPU ready time, in simple terms?
It is the amount of time a VM’s virtual CPU was ready and waiting to run but had to wait for the physical host to schedule it, typically because other VMs on the same host were also competing for CPU time.
What is memory ballooning?
It is a mechanism the hypervisor uses to reclaim memory from a VM that the guest OS believes it still has available, which can produce performance symptoms inside the guest without an obvious guest-level cause.
Is there setup involved in enabling host-level visibility?
Yes. Connecting to a VMware vCenter Server or a Hyper-V host requires configuration and appropriate credentials or permissions. This is genuinely worth a guided walkthrough with a Solutions Architect the first time it is set up.
If you are virtualized and not seeing host-layer metrics alongside your SQL data, you may be missing the actual root cause of performance issues on a regular basis. This is worth bringing in a Solutions Architect for because there is real setup involved, and the value is significant once host-level and SQL-level data are sitting side by side.
SQL Diagnostic Manager for SQL Server
SQL Diagnostic Manager for SQL Server
SQL Diagnostic Manager for SQL Server
SQL Diagnostic Manager for SQL Server
Contact our sales team to get a personalized demo of our database management software for SQL Server!
