In a normal Windows installation, the filesystem abstraction is the only layer between the OS and the abstraction provided by the SSD controller.
When using a virtual VHD/VHDX filesystem, it inserts another software layer. And my feeling is that the impact on performance might be heavier on a SSD than on a HDD. My reasoning: it's not about the speed of reading/writing the file on a slow HDD, but the delay introduced by the software that translates to/from VHD/VHDX on an otherwise very fast NVMe SSD.
Am I wrong?
Your reasoning is actually quite sound, and you're not wrong—though the reality is a bit more nuanced than "heavier impact on SSD vs HDD."
Where Your Intuition is Correct
Latency amplification is real. The VHD/VHDX layer introduces:
- Additional context switches and kernel transitions
- File system translation overhead (the VHD is itself a file on NTFS/ReFS)
- Buffering/caching indirection that can disrupt the low-latency path NVMe SSDs are optimized for
On an NVMe SSD with ~100µs latency, adding even 500µs of software overhead is a 5x relative penalty. On a HDD with 10ms seek times, that same 500µs is barely noticeable (5% overhead).
Where It Gets More Complex
| Factor | Impact |
|---|---|
| Sequential vs Random I/O | VHD overhead matters less for large sequential transfers where throughput dominates; it hurts most with small random I/O where NVMe shines |
| Fixed vs Dynamic VHDX | Fixed-size VHDX performs nearly at raw disk speed for sequential reads; dynamic/expanding adds allocation overhead |
| Host filesystem fragmentation | A dynamic VHDX growing on a fragmented NTFS volume hurts more than the VHD layer itself |
| Caching layers | Windows caches VHD blocks aggressively; repeated reads may bypass physical disk entirely |
The Actual Bottleneck Often Isn't What You Think
The VHDX parser in Windows is highly optimized and often memory-bound rather than CPU-bound. The bigger performance hits usually come from:
- Double filesystem overhead: Guest OS → VHDX file → Host NTFS → SSD controller
- Write-through requirements: If the VHD is mounted with certain flags or for Hyper-V, bypassing caches
- Alignment issues: VHD block boundaries misaligned with host filesystem clusters or SSD pages
The Verdict
You're right that proportionally, the VHD layer extracts a higher toll from fast storage. A modern NVMe SSD might drop from 7GB/s to 3-4GB/s sequential throughput through a VHDX—still fast, but a 40-50% haircut. The same VHDX on a HDD might drop from 200MB/s to 180MB/s (10%).
However, for many real-world workloads, the difference is less dramatic than the raw numbers suggest because:
- Most applications aren't I/O bound at NVMe speeds anyway
- Windows' VHD stack has gotten significantly smarter (sparse files, TRIM pass-through, etc.)
Practical takeaway: If you're running latency-sensitive workloads (databases, heavy compilation) on virtual disks, fixed VHDX on a dedicated volume with proper alignment minimizes the penalty. For general use, the convenience usually outweighs the cost.