我正在尝试理解（并理想地修复）我在与 Hyper-V 结合使用故障转移群集和群集共享卷时注意到的一个特别烦人的现象。似乎在高负载下，当 CSV 后端存储以相当大的延迟（>3 秒）响应所有连接的群集节点的所有请求时，会触发“无响应”情况并关闭持有该资源的资源托管子系统 (RHS) 进程，从而也会使相应的 CSV 短时间内脱机（直到重新启动 RHS 进程）。
该日志包含来自 RHS 的事件 2051 的条目“[RES] 物理磁盘：IsAlive 健全性检查失败！，待处理的 IO 已完成，状态为 170。”后面跟着一些条目，表明 CSV 被强制删除并重新附加。
由于 CSV 用于托管 Hyper-V 客户机的存储，因此 Hyper-V 随后会在受影响的 CSV 上存储的虚拟机上设置“无法连接到虚拟机配置存储”标记，然后关闭它们。即使它没有足够快地关闭每个受影响的客户机，客户机的磁盘访问请求也会在停机期间返回错误，导致客户机在下次重新启动之前无法使用。
现在，由于这种情况只发生在边缘条件下，而且不容易重现，所以我没有太多机会来验证可能的解决方案。读完这， 和那我假设，某些 CSV I/O 操作请求（可能，但不一定是预留 - 我知道预留仅用于 FS 元数据写入，这种情况应该不常见）由于超时而失败，这随后使整个资源处于一种失败状态。但这给我留下了一些疑问：
Hyper-V 真的必须关闭无法访问存储的虚拟机吗？或者对客户机的存储访问请求做出失败响应？难道它不能简单地冻结执行，直到存储恢复吗？
我该如何调整 RHS 的检查，使其不因后端存储的简单过载情况而失败？