Event ID 129 (StorPort) or Latency >50ms in PerfMon

Fix Virtual Disk I/O Latency Spikes on Hyper-V 2019

Server & Cloud Intermediate 👁 6 views 📅 Jun 15, 2026

Virtual disk latency spikes above 200ms during peak load on Hyper-V 2019. Root cause: host-side storage queue depth misconfiguration or disk fragmentation inside the guest.

You're running a SQL Server 2019 VM on Hyper-V 2019 with a 2TB VHDX on a RAID10 array of 10K SAS drives. Every day between 2:00 PM and 3:00 PM, when your ETL job runs, the VM's disk latency spikes from a normal 5ms to over 300ms. The host Event Viewer shows Event ID 129 from StorPort: "Reset to device... issued." Your users see timeouts.

I've seen this exact pattern a dozen times. The root cause is almost never the storage itself—it's how Hyper-V talks to that storage. Two things go wrong: either the host's storage queue depth is too shallow, or the guest's VHDX is fragmented to hell. Let's fix both.

What's actually happening?

Hyper-V passes I/O requests to the physical storage adapter. Each adapter has a queue—think of it as a line of commands waiting for the disk. The default queue depth in Windows Server is 32 for SCSI and 254 for NVMe. If you're on a RAID controller (like a Dell PERC or HP Smart Array), the default might be as low as 8. When your SQL workload sends 100+ concurrent I/O requests, they pile up. The disk spins faster trying to catch up, latency climbs, and eventually StorPort says "I can't handle this" and resets the path.

Second problem: inside the guest, that 2TB VHDX gets fragmented over time. defrag reports show 15%+ fragmentation for the VHDX file on the host's volume. That means the disk head is jumping all over the platters to find blocks. On spinning disks, that's a latency killer.

Fix 1: Increase the host storage queue depth

  1. Log into your Hyper-V host as an admin. Open a PowerShell session as Administrator.
  2. Run Get-StorageAdapter | Select-Object FriendlyName, QueueDepth
    What you'll see: A list of storage adapters and their current queue depths. If it's 32 or less, that's your bottleneck.
  3. For a Broadcom/Avago SAS adapter (common in Dell servers), run:
    Set-StorageAdapter -FriendlyName "RAID Controller" -QueueDepth 254
    What you'll see: No output—that's fine. But if you run the Get cmd again, you'll see 254.
  4. For older HP SmartArray controllers, you might need the HP SSA CLI tool. Open command prompt as admin and run:
    ssacli ctrl slot=0 modify queuedepth=254
    What you'll see: "Queue depth set to 254."
  5. Reboot the host. This setting sticks, but a reboot ensures the driver picks it up cleanly. After reboot, verify with the Get cmd again.
  6. Wait for your next ETL window. Check latency in the guest using PerfMon counter \LogicalDisk(*)\Avg. Disk sec/Transfer. You should see peaks drop from 300ms to under 50ms.

Fix 2: Defrag the VHDX on the host

  1. On the Hyper-V host, open an admin PowerShell window.
  2. First, shut down the guest VM that uses the VHDX. You can't defrag a file that's locked. Use:
    Stop-VM -Name "YourVMName" -Force
    What you'll see: "YourVMName" state changes to Off.
  3. Now run a defrag on the host volume where the VHDX lives. For example, if it's on D:\VMs, run:
    Optimize-Volume -DriveLetter D -Defrag -Verbose
    What you'll see: "D: - Total fragmented space: 15%... Processing file: YourVM.vhdx..." This can take 20-60 minutes for a 2TB file. Don't cancel it.
  4. When it finishes, run Get-Volume D | Format-List FragmentationPercentage. Anything under 3% is fine.
  5. Start the VM back up: Start-VM -Name "YourVMName".
  6. Inside the guest, run a disk defrag too—especially for SQL Server data files. Open an admin CMD in the guest and run:
    defrag C: /U /V
    What you'll see: "Pre-defragmentation report: 22% fragmentation... Post-defragmentation report: 1% fragmentation."

What to check if it still fails

If latency stays above 100ms after adjusting queue depth and defragging, look at these three things:

  • Is your storage subsystem overloaded? Check the host's \PhysicalDisk(*)\Avg. Disk Queue Length in PerfMon. If it's consistently above 2 per spindle during the spike, you need more spindles or faster drives. SSDs would fix this instantly.
  • Are you using dynamic VHDX? Stop. Dynamic VHDX writes grow the file on-the-fly, and that causes fragmentation inside the host. Switch to fixed-size VHDX. You'll need to create a new fixed disk and copy data over with robocopy.
  • Is the virtual SCSI controller set to SSD? In Hyper-V Manager, go to VM Settings > SCSI Controller > and check "Enable virtual SSD". If your host storage is SSDs, enable this. It tells Windows inside the guest to use TRIM commands. If your host uses spinning disks, leave it off—enabling it on HDDs actually hurts performance.
One last tip: If you're on Hyper-V 2012R2 or 2016, upgrade to 2019 or 2022. Microsoft fixed a major StorPort bug in 2019 that caused Event ID 129 even with correct queue depth. I've seen that fix alone drop latency by 80%.

Was this solution helpful?