Hyper-V storage decisions are made early and changed slowly. The virtual disk format you choose, where you store those files, and how you carve up physical storage – these choices sit underneath every VM on your host. These decisions are easy to defer until something breaks or capacity planning falls apart six months into production.
This guide covers how Hyper-V storage actually works: disk formats, fixed vs dynamic tradeoffs, where VHDX files should live, pass-through disks, Storage Spaces, and what checkpoints quietly do to your storage over time – and how to recover when they go wrong (see the Hyper-V Checkpoint & AVHDX Troubleshooting guide). The goal is to make the right decisions before they become expensive to reverse.
- Use VHDX for current Hyper-V deployments; retain VHD only for a verified backward-compatibility requirement
- Fixed disks eliminate silent overcommit at the VHDX file layer; underlying thin-provisioned pools, LUNs, or arrays still require their own capacity monitoring
- Move the default VHDX path off the OS drive before creating any VMs
- SMB 3.x is a first-class Hyper-V storage option – SMB Multichannel is enabled by default and strongly recommended, with correct permissions for every Hyper-V host computer account and the cluster computer account when applicable; protocol support alone doesn’t make the path highly available
- Pass-through disks are rarely necessary today – use them only when representative testing shows a supported VHDX, Virtual Fibre Channel, or DDA design can’t meet the requirement
- Checkpoints grow storage silently – every checkpoint needs an owner, a reason, and a deletion date
VHD vs VHDX – What Actually Changed
VHD is the original Hyper-V virtual hard disk format, effectively capped around 2TB and lacking the metadata resiliency improvements introduced with VHDX. VHDX replaced it in Windows Server 2012 and has been the standard format for Hyper-V virtual hard disks ever since.
The differences that matter operationally:
- Size limit: VHD caps around 2TB. VHDX supports up to 64TB.
- Corruption resilience: VHDX uses transaction logging on metadata writes. If the host loses power during a metadata operation, VHDX can recover on next mount.
- Large-sector support: VHDX provides improved alignment for large-sector storage and can expose 4-KB logical sectors to compatible guests and applications. Current Hyper-V versions can also create properly aligned VHD files, but VHDX has the more complete large-sector design.
- TRIM/UNMAP support: VHDX can pass guest deallocation notifications through supported SCSI, enlightened IDE, or Virtual Fibre Channel paths so the host and underlying storage can reclaim unused blocks. Visible VHDX file shrink isn’t guaranteed automatically.
When VHD still appears: legacy Hyper-V hosts (2008 R2, 2012), exported VMs from old infrastructure, or VMs migrated from VMware with older tooling. If you receive a VHD, convert it to VHDX before it goes into production. The process is offline and straightforward:
# Convert VHD to dynamic VHDX
Convert-VHD -Path old.vhd -DestinationPath new.vhdx -VHDType Dynamic
# Use -VHDType Fixed if you intentionally want a fixed-size VHDX
Convert-VHD -Path old.vhd -DestinationPath new.vhdx -VHDType FixedUse VHDX for new VMs on Windows Server 2022 and 2025. Keep or create VHD only when a documented backward-compatibility or tooling requirement means the VM disk needs to work with an earlier platform that doesn’t support VHDX. For the full format specification, see Microsoft Learn: Hyper-V Virtual Hard Disks.
Fixed vs Dynamic Disks: Choosing the Right Default
This is a high-impact Hyper-V storage decision, and the framing repeated in most documentation is outdated. Fragmentation and block-mapping overhead still exist, but their practical impact depends on the host filesystem, storage medium, workload, and existing fragmentation. On modern flash storage, capacity control is often the larger operational difference, while fixed VHDX still retains the lower-overhead data path. Dynamic VHDX files still allocate blocks and update metadata during first writes, which adds I/O and CPU overhead. The larger operational difference is capacity risk: fixed disks reserve their full size at the VHDX file layer, while dynamic disks require active monitoring of the hosting volume. See Microsoft’s Hyper-V storage I/O performance guidance for the underlying fixed vs dynamic tradeoffs.
Dynamic VHDX
A dynamic disk starts small and grows as the guest writes data. A dynamic VHDX roughly tracks blocks that have been allocated through guest writes, plus VHDX metadata – its host allocation doesn’t necessarily match the used-space figure shown inside the guest. When the guest, virtual controller, host filesystem, and underlying storage all support TRIM/UNMAP, deleted ranges can be reported down the stack so unused storage can be reclaimed. Do not assume every deleted guest file immediately reduces the visible VHDX file size.
Advantages: storage flexibility, faster initial provisioning, lower physical footprint for lightly-used VMs.
Where dynamic disks create real operational problems:
- Overcommit can remain invisible during normal operation unless the hosting volume is monitored. If you provision five 500GB dynamic disks across VMs but only have 1TB of physical storage, it works until it doesn’t. Hyper-V can log low-space warnings and place affected VMs into a
Critical - Pausedstate when the hosting volume runs out of free space, but those safeguards are late-stage protection, not a capacity-management system. When the hosting volume can no longer satisfy writes, applications inside the paused or failing VM can still become unavailable, so monitoring needs to alert well before that point. - Capacity planning needs both sides of the picture. Host-side VHDX sizes show current allocation, but they don’t show how much additional growth the guests can still demand – capacity planning needs both host-volume free space and guest-side used/free capacity, not just one or the other.
Fixed VHDX
A fixed disk allocates the full declared size on the host immediately. A 100GB fixed VHDX occupies 100GB on the host from the moment it’s created.
Advantages: predictable file-level allocation, straightforward host-volume capacity planning, and no overcommit at the VHDX layer. This does not remove overcommit risk from an underlying thin Storage Spaces virtual disk, SAN LUN, NAS volume, or storage array – those layers still need their own monitoring. On spinning disk, marginally better write throughput due to no allocation overhead mid-write; on NVMe and fast SSD, the gap narrows but active monitoring still matters more than raw throughput for most production decisions.
Disadvantages: reserves the full file size immediately and can take longer to create, copy, export, or back up depending on the filesystem and storage stack – ReFS and storage-offload features can substantially reduce some of these operation times. Consumes storage whether the guest needs it or not.
Fixed vs Dynamic by Workload
| Workload | Recommended type | Reason |
|---|---|---|
| Production database (SQL, Exchange) | Fixed, unless a monitored dynamic design is validated | Lower allocation overhead and predictable VHDX-layer capacity |
| General production server | Fixed or Dynamic with active monitoring | Choose predictability or efficiency; monitor every thin layer, not just the VHDX |
| Dev/test VMs | Dynamic | Fast provisioning and storage efficiency |
| Homelab general use | Dynamic | Overcommit risk is manageable at small scale |
| Template/base images | Dynamic, or a controlled differencing design | Lower footprint; use differencing disks only when the parent image is immutable, protected from relocation or modification, and managed through a documented lifecycle |
Conversion between types is an offline operation whose duration depends heavily on the disk type, used capacity, storage performance, ODX support, and destination format. Measure it on representative storage before assigning a maintenance window – don’t plan a fixed-duration window from a generic estimate.
Thin Provisioning and Capacity Planning
Dynamic VHDX is one form of thin provisioning. The concept extends further across a typical Hyper-V storage stack:
- Dynamic VHDX – thin at the virtual disk layer
- Storage Spaces thin provisioning – thin at the storage pool layer
- iSCSI thin LUNs – thin at the SAN/NAS layer
- Thin NAS volumes – thin at the physical storage layer
Thin provisioning can stack. A dynamic VHDX on a thin LUN on a thin storage pool can consume far less physical space than the sum of its allocated sizes – until all of those layers try to allocate simultaneously. When the lowest physical layer can no longer allocate storage, upper layers begin failing writes. Hyper-V can pause affected VMs in a Critical state, while guest applications and dependent services become unavailable. The incident is then traced back through multiple thin-provisioned layers to a pool that was overcommitted silently for months.
The practical rule: know which layers are thin in your stack and set monitoring thresholds with enough headroom for the fastest credible growth event, checkpoint merge, backup operation, rebuild, and thin-provisioned lower layers. An 80% warning threshold can be a reasonable starting point, but validate it against the environment’s actual growth rate and recovery time rather than treating it as a fixed rule.
For Storage Spaces, monitor pool and virtual disk health proactively. At minimum:
# Check storage pool health and available capacity (excludes primordial pools)
Get-StoragePool | Where-Object IsPrimordial -eq $false | Select-Object FriendlyName, HealthStatus, OperationalStatus, Size, AllocatedSize, @{Name="FreeBytes";Expression={$_.Size - $_.AllocatedSize}}
# Check virtual disk health (both HealthStatus and OperationalStatus)
Get-VirtualDisk | Where-Object { $_.HealthStatus -ne "Healthy" -or $_.OperationalStatus -notcontains "OK" } | Select-Object FriendlyName, HealthStatus, OperationalStatus, ResiliencySettingName, Size
# Check physical disk state
Get-PhysicalDisk | Where-Object { $_.HealthStatus -ne "Healthy" -or $_.OperationalStatus -notcontains "OK" } | Select-Object FriendlyName, SerialNumber, HealthStatus, OperationalStatus, MediaType, Size
# Check active storage jobs (rebuild, repair)
Get-StorageJobIn production, wire these checks into monitoring and alerting. Reviewing them manually after users report write failures is already too late.
Where to Store Your VHDX Files
The physical location of VHDX files affects performance, availability, and the blast radius of a failure. Many competing articles say “use dedicated storage” and move on. The operational consequences deserve more space.
The OS Drive Mistake
The Hyper-V default VHDX location on a fresh installation is C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks. That’s the OS volume.
Storing production VHDX files on the OS drive creates a predictable failure chain: Windows updates consume space, logs accumulate, the pagefile sits there, dynamic VHDX files grow – and eventually the OS drive fills. When it does, the host OS becomes unstable before the issue is detected. Meanwhile, all VMs on that path are fighting the same I/O queue as the operating system.
Change the default VHDX path in Hyper-V Manager -> Hyper-V Settings -> Virtual Hard Disks before creating any VMs. This is one of the first configuration tasks after installing Hyper-V – covered in the Hyper-V Post-Install Checklist.
Local Storage: Simple, Fast, Limited Mobility
A dedicated local NVMe or SSD volume can provide excellent low-latency performance with the simplest operational model. For single-host environments, it’s the right default. No network dependency, no additional infrastructure, no configuration complexity.
The main limitation is automatic failover, not VM mobility. A standalone host with local storage can’t automatically restart its VMs on another host after a hardware failure. However, Hyper-V supports shared-nothing live migration, which can move a running VM and its storage between compatible hosts without shared storage. This is planned mobility, not high availability. For cluster storage setup where automatic failover is the goal, see the Hyper-V Failover Clustering guide.
SMB 3.x: First-Class Hyper-V Storage
SMB 3.x is a supported and production-tested Hyper-V storage path. Windows Server 2012 introduced SMB 3.0 improvements that made Hyper-V over SMB a viable production design, including capabilities such as SMB Transparent Failover in clustered file server scenarios.
What SMB 3.x actually requires to work well:
- SMB Multichannel: enabled by default and strongly recommended for resilient production storage. It automatically uses multiple eligible NICs, RSS queues, teamed adapters, or RDMA paths when available. Hyper-V over SMB can function on a single path, but that path becomes a single point of failure and can become a performance bottleneck under sustained storage load.
- Correct permissions: grant the required share and NTFS permissions to every Hyper-V host computer account. For a Hyper-V failover cluster, include the cluster computer account as well. SYSTEM and the approved Hyper-V administration identities also need the required control on the application share. This is a common source of SMB storage misconfiguration and can be tricky to diagnose if you don’t know to look for it.
- Network design: use dedicated storage paths or a validated converged design with redundant uplinks, VLAN separation, QoS, and enough bandwidth for worst-case VM and storage traffic. Hyper-V networking design matters directly for SMB storage performance – see Hyper-V Networking: Virtual Switches, VLANs, and SET for converged networking design guidance.
SMB 3 protocol support alone doesn’t make the storage path highly available. For clustered Hyper-V workloads, use a continuously available applications share backed by a resilient Scale-Out File Server or a supported HA NAS architecture – a standalone SMB 3 share remains a single point of failure. SMB 3.x is a strong option when that continuously available architecture already exists and the team can provide correct permissions, redundant networking, and validated backup support. See Microsoft’s Windows Server storage architectures and SMB Multichannel documentation for configuration details.
Confirm Multichannel is actually active before relying on it:
# Confirm SMB Multichannel is enabled
Get-SmbClientConfiguration | Select-Object EnableMultichannel
Get-SmbServerConfiguration | Select-Object EnableMultichannel
# Inspect client/server interfaces visible to SMB
Get-SmbClientNetworkInterface
Get-SmbServerNetworkInterface
# Run while an SMB workload is active
Get-SmbMultichannelConnection
Get-SmbMultichannelConnection -IncludeNotSelectediSCSI: When It Makes Sense
iSCSI presents block storage over IP. From Hyper-V’s perspective, an iSCSI LUN looks like a local disk. iSCSI uses initiator sessions and LUN ownership. A single-path connection can function, but production designs should use redundant paths and MPIO where supported by the storage vendor. For a standalone single-host LUN, the filesystem choice depends on the storage vendor and required features. For SAN-backed clustered storage, use NTFS when you need Direct I/O, TRIM/UNMAP, thin-provisioning integration, or ODX. A SAN-attached CSV formatted with ReFS operates through redirected I/O instead of normal Direct I/O.
iSCSI requires the iSCSI Initiator service and a properly configured target (TrueNAS, Synology, or a dedicated SAN). The setup is more involved than SMB. Both SMB and iSCSI can place VM storage outside the Hyper-V host, but their operational models differ: SMB presents file storage and uses share permissions plus SMB Multichannel, while iSCSI presents block devices and uses initiator sessions, MPIO, LUN ownership, filesystem rules, and usually Failover Clustering with CSV for concurrent multi-host access.
- Do not place multiple Hyper-V hosts on the same non-clustered NTFS or ReFS iSCSI LUN
- Without a clustering layer (Failover Clustering + CSV), simultaneous writes from multiple hosts to the same block device will cause filesystem corruption
- iSCSI shared storage requires a supported clustering design – it is not a shortcut to HA without the cluster overhead
- If you need shared storage across hosts, use SMB 3.x or configure Failover Clustering with CSV properly
For new environments, compare SMB and iSCSI as different architectures rather than treating either as the automatic default. SMB provides file-based storage with SMB Multichannel and is typically simpler to configure and troubleshoot when a Windows or NAS file-service platform is already available. iSCSI is the better fit when block storage, an existing SAN, or vendor-specific block features are already part of the environment.
Storage Location Decision Reference
| Storage option | Best for | Key limitation |
|---|---|---|
| Local NVMe/SSD (dedicated volume) | Single host, low-latency local storage | No automatic failover; shared-nothing live migration remains available for planned moves |
| Local SATA/HDD | Budget homelab, archive VMs | Limited IOPS, slow VHDX creation |
| Continuously available SMB 3 share | Multi-host Hyper-V, Live Migration, and HA when backed by a resilient SOFS or supported HA NAS architecture | SMB 3 support alone doesn’t make the file server or backend storage highly available |
| iSCSI | Existing SAN/NAS block-storage infrastructure | Requires initiator and LUN management; production redundant paths should use MPIO, while concurrent multi-host ownership requires Failover Clustering and CSV |
| Pass-through disk | Specialized direct-LUN scenarios after representative testing | No checkpoints and major migration/portability limitations |
Disk Controllers: SCSI and IDE
For Generation 2 VMs, the controller decision is straightforward: use SCSI. Use Generation 2 for guests and boot methods listed as compatible in Microsoft’s current support matrix; use Generation 1 only when the guest OS, boot media, or a legacy device requirement makes it necessary.
- SCSI: supports hot-add and hot-remove of virtual disks without a VM restart, up to 64 disks per controller (4 controllers = 256 total), and is the standard choice for both boot and data disks on Gen 2 VMs.
- IDE: appears on Generation 1 VMs only. Gen 1 boots from IDE; data disks on Gen 1 can still use SCSI. If you’re creating Generation 1 VMs in 2026, there’s a compatibility reason – but the controller model hasn’t changed.
Generation 2 offers UEFI firmware, Secure Boot support, and SCSI boot – not just a different controller model. See Microsoft Learn: Generation 1 vs Generation 2 virtual machines for the full compatibility matrix.
Hyper-V exposes normal virtual hard disks through IDE or SCSI controllers – there is no general-purpose virtual NVMe controller for VHDX. A physical NVMe device can be assigned through Discrete Device Assignment in supported hardware configurations – this is PCIe passthrough, not a virtual NVMe controller. For standard DDA storage-device assignments, plan on no Live Migration, VM Save/Restore, Dynamic Memory, or normal HA-cluster mobility unless current device-specific Microsoft documentation explicitly states otherwise. For most Hyper-V operators, the practical controller decision is: use Generation 2 VMs with SCSI controllers unless a specific workload and OS combination gives you a tested reason to do otherwise.
Pass-Through Disks: Why They Mostly Disappeared
Pass-through disks give a VM direct access to a physical disk or LUN, bypassing the VHDX layer entirely. In 2012-2016, this was a meaningful Hyper-V storage performance option. VHDX had measurable overhead that showed up in database benchmark comparisons.
That picture has changed. Modern VHDX supports TRIM, UNMAP, and large sector alignment, and the Hyper-V storage stack has been optimized significantly across Windows Server 2016, 2019, 2022, and 2025.
Microsoft recommends avoiding pass-through disks because their migration and management limitations usually outweigh their reduced root-partition filesystem overhead. Compare them only with workload-specific benchmarks on the actual storage stack rather than assuming a general performance conclusion applies to your workload.
What pass-through costs you: it complicates export, migration, Replica, and checkpoint workflows because the VM depends on a physical disk or LUN outside the portable VHDX file. Checkpoints are not supported for pass-through disks. Whether the VM must be powered off to add or remove a pass-through disk depends on the controller, host version, and configuration – verify the specific behavior rather than assuming it always requires downtime.
If you’re evaluating pass-through for a specific workload, test fixed VHDX on local NVMe first. Use pass-through only when representative testing shows that a supported VHDX, Virtual Fibre Channel, or DDA design can’t meet the requirement. DDA can solve a device-access requirement, but it exchanges virtual-disk portability for direct hardware assignment – it isn’t a drop-in VHDX replacement for VMs that need routine migration or HA.
Storage Spaces and Hyper-V
Storage Spaces is Windows Server’s software-defined storage layer. It pools physical disks into a storage pool and presents virtual disks to the OS. For Hyper-V, you store VHDX files on a volume that lives on a Storage Space.
Storage Spaces on a Single Host
On a single Hyper-V host, Storage Spaces provides software RAID across local disks without a hardware RAID card: mirror (2-way or 3-way), parity, or simple (no redundancy) configurations. Standalone Storage Spaces can use storage tiers to place frequently accessed extents on faster media and colder data on capacity media. Tiering is not the same as the persistent real-time storage pool cache used by Storage Spaces Direct – Microsoft doesn’t support the Storage Bus Layer cache in a single-server Storage Spaces configuration.
This is a reasonable choice for operators who want disk-level redundancy without buying a hardware RAID controller. The management overhead on a single host is low.
Storage Spaces Is Not ZFS
Operators coming from Proxmox with ZFS experience sometimes expect Storage Spaces to behave similarly. Storage Spaces and ReFS still don’t use the same architecture or operational model as ZFS. ReFS always protects metadata with checksums and can optionally protect file data through integrity streams. It also includes a background integrity scrubber that periodically checks infrequently accessed data (every four weeks by default) and can trigger repair when resilient Storage Spaces provides another valid copy. The important difference is not the complete absence of scrubbing, but how integrity streams, repair, monitoring, caching, and operational tooling differ from ZFS. The ReFS scrubber can validate file data only where integrity streams are enabled – integrity streams can add performance overhead and aren’t enabled for every workload by default.
Neither is universally superior. They have different failure modes and different operational mental models. Coming from ZFS, expect to rebuild some instincts around how storage health is monitored and validated.
Storage Spaces Direct (S2D)
S2D extends Storage Spaces across multiple cluster nodes, pooling local storage from all nodes into a shared pool. It requires a supported clustered Windows Server design, validated hardware, local storage on each node, and high-bandwidth, low-latency networking. Storage Spaces Direct in Windows Server requires Datacenter edition and supports 2 to 16 servers. For small 2-3 node clusters, Microsoft lists 10GbE or faster as the minimum interconnect; for 4+ node or high-performance deployments, 25GbE and RDMA-capable adapters are recommended. Treat S2D as cluster infrastructure, not a simple storage toggle. See Microsoft’s Storage Spaces Direct overview, hardware requirements, and deployment guide.
S2D belongs in the failover clustering context. If you’re building a validated cluster and want a hyperconverged local-disk architecture, S2D is one supported option – it should be selected only after hardware validation, network design, licensing, backup compatibility, and failure testing, not chosen by default because it’s technically capable. If you’re not building a cluster, Storage Spaces on a single host is a different and simpler tool. See Hyper-V Failover Clustering: Quorum, CSV, and Live Migration for cluster storage design – Storage Spaces Direct belongs in that context.
Complexity should be earned. S2D rewards operators who have dedicated storage networking, validated hardware, and the operational capacity to manage a cluster. Adding it to a two-node homelab because it seems powerful adds significant overhead without proportional benefit.
Checkpoints and What They Do to Storage
Checkpoints are frequently misunderstood at the Hyper-V storage layer. Creating one feels lightweight. The storage consequences accumulate silently.
When you create a checkpoint, Hyper-V freezes the base VHDX and creates an AVHDX differencing disk. From that point, all writes go to the AVHDX. The base VHDX becomes read-only. A busy VM with months of writes on an AVHDX can have a differencing file as large as or larger than the original base VHDX. Operators who create checkpoints “just in case” and don’t delete them end up consuming far more Hyper-V storage than expected.
When you delete a checkpoint: Hyper-V merges the selected AVHDX differencing disk into its immediate parent. Each newly created AVHDX is a child of the disk that was active before it – either the previous AVHDX or the base VHDX. In a checkpoint chain, consolidation proceeds from child to parent in the correct order until the remaining state is merged into the final VHDX structure. Never delete AVHDX files manually. Hyper-V supports online checkpoint merge, so the VM can remain running during a normal supported merge – offline and manual recovery scenarios can behave differently. The online merge adds storage I/O and can reduce VM or host storage performance until completion – the impact depends on AVHDX size, chain depth, available free space, and underlying storage performance. Before a large merge, confirm the hosting volume has enough free space and that backup software isn’t holding the chain open. Long checkpoint chains multiply the merge time – a chain that took months to build can take hours to merge. See Microsoft’s guidance on using Hyper-V checkpoints and on merging checkpoints with multiple differencing disks.
Production vs Standard checkpoints: production checkpoints (default since Windows Server 2016) create a data-consistent state without saving the VM’s memory, using VSS inside supported Windows guests and filesystem freeze mechanisms inside supported Linux guests. The default Production setting can fall back to a Standard checkpoint if the production checkpoint fails. For workloads where a saved-memory checkpoint is unacceptable, set ProductionOnly so the operation fails instead of silently creating a Standard checkpoint:
Set-VM -Name "VM01" -CheckpointType ProductionOnlyStandard checkpoints save VM state including RAM – useful for quick test rollbacks, not appropriate for production systems running databases or transactional workloads.
The practical rule: every checkpoint should have an owner, a reason, and a deletion date. If nobody owns it, it becomes storage debt. Long-running checkpoint chains are not a backup strategy – they are delayed storage consumption with a performance penalty on merge.
Checkpoints are not backups. A checkpoint chain stored on the same host volume gives rollback capability but no protection against host storage failure, accidental deletion, or host-level corruption. The Hyper-V Backup Strategy article covers the boundary between checkpoints and actual backups – these are not interchangeable tools.
Hyper-V Storage Best Practices
| Decision | Recommendation | Reasoning |
|---|---|---|
| Disk format | VHDX by default; VHD only for a verified backward-compatibility requirement | VHDX supports 64TB, metadata resilience, larger sectors, and UNMAP |
| Disk type – homelab | Dynamic | Flexibility outweighs capacity planning complexity at small scale |
| Disk type – production | Fixed preferred where predictable VHDX-layer allocation and lowest overhead matter; Dynamic acceptable with active monitoring across every thin-provisioned layer | Fixed removes VHDX-layer overcommit; dynamic viable when alerting covers every layer, not just the VHDX |
| VM generation | Generation 2 unless legacy compatibility requires Gen 1 | UEFI, Secure Boot, SCSI boot disk, modern security features |
| Controller | SCSI for modern VM disks | Hot-add support, 64 disks per controller, standard for Gen 2 boot and data |
| Default VHDX path | Move off OS drive before first VM | OS drive contention + disk fill cascades to host instability |
| Single-host storage | Local NVMe/SSD on a dedicated volume | Excellent low-latency performance with the simplest local failure domain |
| Multi-host HA storage | Choose validated SAN/CSV, continuously available SMB 3 storage, or S2D based on failure domains, scale, support, and operational ownership | Architecture depends on failure domains, scale, vendor support, and operational capacity |
| Pass-through disks | Avoid unless representative testing shows VHDX can’t meet the requirement | Complicates migration, checkpoints, and portability |
| Checkpoints | Short-lived, owned, with deletion date | Long chains = slow merges + unexpected storage growth |
| Storage Spaces | Single host: viable; S2D: validated cluster context only | Complexity budget must match infrastructure scale |
Final Thoughts
Most Hyper-V environments need a supported VHDX design, storage separated from the host OS, active capacity monitoring, and an architecture matched to the required failure domain. The correct location may be local storage, SAN/CSV, continuously available SMB, or S2D.
Storage Spaces Direct, pass-through disks, iSCSI, and tiered storage earn their place when the workload demands them. The pattern that creates operational problems is adding storage complexity before the requirement is clear. Start with the simplest architecture that meets the workload’s performance, availability, migration, backup, and recovery requirements, and add storage complexity only when a validated requirement justifies it.
Next in the Hyper-V cluster: backup strategy, where the checkpoint limitations covered here become the starting point rather than the ending one.
FAQ
Should Hyper-V VMs be stored on the C: drive?
No. The default Hyper-V virtual hard disk location points to the OS volume on a fresh installation. Change it before creating any VMs. Storing VHDX files on the OS drive creates storage I/O contention and risks filling the drive as VM data grows – which can destabilize the host OS before you notice. In Hyper-V Manager -> Hyper-V Settings, update the default Virtual Hard Disks path to a dedicated data volume. This is one of the first tasks in the Hyper-V Post-Install Checklist.
Should I use fixed or dynamic VHDX for production VMs?
Fixed is the safer default for production. Fixed VHDX reserves its full size on the host filesystem, which removes overcommit at the virtual-disk-file layer – it does not reserve physical capacity inside an underlying thin-provisioned SAN, Storage Spaces pool, or storage appliance, so those layers still need their own monitoring. Fixed disks allocate their full size immediately, which makes host-level capacity planning straightforward. Dynamic is acceptable in production when storage monitoring covers every thin layer and thresholds are set before physical capacity runs out anywhere in the stack.
Is dynamic VHDX slower than fixed VHDX?
Dynamic VHDX adds block-allocation and metadata overhead on first writes. On fast modern storage that overhead may be small for many workloads, but fixed VHDX remains the lower-overhead option. Measure the actual application workload rather than assuming the difference is always negligible – the storage medium still matters more than the disk type for most deployments, but “negligible” isn’t a safe universal assumption for latency-sensitive production workloads.
What’s the difference between VHD and VHDX?
VHD is the legacy format: effectively capped around 2TB and without the VHDX metadata-resiliency and UNMAP features. Use VHDX for current Hyper-V deployments. Retain or create VHD only when a documented backward-compatibility or tooling requirement requires support for an earlier Hyper-V platform.
Can I store Hyper-V VMs on a network share (SMB)?
Yes, but distinguish protocol support from storage availability. SMB 3.x is a first-class supported storage path for Hyper-V, and SMB Multichannel is enabled by default and strongly recommended – it automatically uses multiple eligible NICs, RSS queues, or RDMA paths when available. A single-path design remains a single point of failure and can become a performance bottleneck under sustained load. A standalone SMB 3 share can host VM files, but Hyper-V HA requires a continuously available share backed by a resilient file-server and backend-storage design, such as a Scale-Out File Server. The share and its NTFS permissions need to grant access to every Hyper-V host computer account, and to the cluster computer account for a Hyper-V failover cluster, plus SYSTEM and the approved administration identities.
What is a pass-through disk and do I need one?
A pass-through disk gives a VM direct access to a physical disk or LUN, bypassing VHDX entirely. Microsoft recommends avoiding pass-through disks because they complicate export, migration, Replica, and checkpoints – checkpoints aren’t supported for pass-through disks at all. Use one only when representative testing on the actual storage stack proves that a supported VHDX, Virtual Fibre Channel, or DDA design can’t meet the requirement. Test fixed VHDX on local NVMe first.
What happens to storage when I delete a checkpoint?
Hyper-V merges the selected AVHDX into its immediate parent. In a multi-checkpoint chain, each newer child disk must be consolidated into the previous parent disk in the correct order before the chain is fully merged – never delete AVHDX files manually. The VM can remain running during a normal online merge, but it adds storage I/O and can reduce performance until completion – the impact depends on AVHDX size, chain depth, free space, and underlying storage performance. For large differencing files or long chains, the merge can take significant time. Long-running checkpoint chains are a recurring source of unexpected Hyper-V storage consumption and can degrade host performance during merge operations.
How large can a VHDX file be?
64TB. In practice, most environments never approach this limit, but it removes the ~2TB ceiling that made VHD impractical for large database or file server workloads on modern Hyper-V hosts.
Is Storage Spaces a good option for Hyper-V storage?
For a single host, Storage Spaces is a reasonable alternative to hardware RAID – it pools local disks and provides mirror or parity resilience without a RAID controller. It isn’t ZFS: the operational model differs, though ReFS integrity streams plus a background scrubber (every four weeks by default) do provide proactive checksum-based validation, not a complete absence of scrubbing. Storage Spaces Direct (the multi-node cluster variant) is a different product with significantly higher operational overhead and belongs in a validated cluster deployment, not a single-host setup.
Hyper-V Series
12 articles — Windows Server 2025 · Networking · Storage · Backup · Clustering