Hyper-V host cache support boundaries for shared virtual hard disks

Answer

Read-only host cache is not considered safe for a virtual hard disk shared by multiple VMs on a single host merely because access is local. The shared-disk restriction concerns cache coherence under concurrent attachment, not only cross-host access. Documented Hyper-V guidance for guest failover-cluster shared virtual hard disks is to disable host caching; enabling it risks stale reads or corruption when any attached VM writes. Until documentation for your exact Windows Server build explicitly permits it, treat both standard shared VHDX and VHD Set (.vhds/.avhdx) as unsafe for host caching.

Confirmed facts versus likely explanation

Confirmed facts

• Hyper-V maintains a host-level read cache in host memory, separate from the guest file-system cache.
• Documented guidance for shared virtual hard disks in guest failover clusters is to disable host caching.
• Concurrent writes from multiple VMs can make the host cache incoherent, causing stale reads or corruption.
• A host-memory cache does not migrate coherently to a destination host during live migration.

Likely explanation

The cache is not coherent with I/O issued by other VMs on the same host, and it is not transferred to a destination host during live migration. VM2 can therefore read stale data written by VM1 through the cache. If the disk is truly immutable and never written by any host or guest, staleness is not a risk; that is not the typical shared cluster-disk case.

Version-sensitive enforcement

Enforcement varies by Windows Server build and by disk format. I do not have a confirmed build-level matrix showing whether Hyper-V ignores, disables, or rejects host cache for standard shared VHDX or VHD Set. Absence of a cache option in VHD Set is not proof that caching is safe. Treat this section as requiring review against your specific build.

Verification steps

1. Record the Windows Server build on every host and identify whether the disk is standard shared VHDX or VHD Set.
2. In Hyper-V Manager, open each VM's settings, select the shared hard drive, and confirm it is marked shared. Note whether any host-cache setting is exposed, enabled, grayed out, or absent.
3. Optionally confirm the attachment with PowerShell: Get-VMHardDiskDrive -VMName <VMName> | Select-Object Path, ControllerType, ControllerNumber, ControllerLocation. This verifies the shared attachment, not the cache state.
4. Run a two-VM concurrent write/read test with host cache enabled, then disabled, and compare results. Repeat after live migration if the disk moves between hosts.
5. Review Hyper-V and storage event logs for cache or shared-VHD errors. Treat silent disabling or ignored settings as unsupported for that configuration.

Missing diagnostic detail

What Windows Server build and disk format (standard shared VHDX or VHD Set) are you using? That determines whether host cache is ignored, disabled, or unsupported, and it changes the recommendation.