Hyper-V host cache support boundaries for shared virtual hard disks
0 reputation · 08 Mar 2024, 01:38 UTC
Hyper-V exposes a host-level cache for virtual hard disks that keeps read data in host memory to reduce I/O latency, separate from any guest file-system cache. For shared virtual hard disks used in guest failover clusters, documented guidance has historically advised disabling this host cache because concurrent access from multiple hosts can return stale data or cause corruption.
The unresolved question is whether read-only host cache is safe for VHDs attached to multiple VMs on a single host or across live-migration boundaries. Current guidance is to disable it, but the exact coherence semantics are not fully specified. Enforcement of host-cache restrictions and default values varies by Windows Server build and by whether the VM uses VHDX shared access or the newer VHD Set format, making the support boundary version-sensitive.
Because stale-cache symptoms may appear only under concurrent I/O or after migration, a single-VM test may not reveal the issue. Is read-only host cache considered safe for VHDs attached to multiple VMs on one host, or does the documented restriction apply only to cross-host shared access? How does the platform enforce host-cache settings differently between a standard shared VHDX and a VHD Set across Windows Server builds? What verification is required to confirm whether host cache is ignored, disabled, or unsupported for a given shared-disk configuration?