Skip to content

Hyper-V Private Cloud Monitoring - Failover Cluster and CSV Integration

Generated support reference. All capabilities · Day-2 triage.

Default conditions below come from the compiled candidate source, not the effective overrides in your management group. Read the monitor-specific knowledge together with the common safety and verification guidance. Microsoft links explain the underlying technology; product thresholds are not Microsoft recommendations.

Hyper-V Failover Cluster

HyperVPrivateCloud.Capability.Cluster.ClusterRole

Cluster-wide collector identity hosted through the cluster core-group ownership path. It gathers node/quorum/network/group/CSV summaries; Microsoft cluster objects remain authoritative for their own resource-level health.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Kind: ClassType.

Identity and monitoring ownership

Base class=System!System.LogicalEntity; hosted=true; singleton=false; declared properties=BoundaryId, ClusterName. Inherited properties also apply. Inspect the exact instance and its monitoring path; inventory-only classes do not acquire health merely by appearing in a diagram.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

What this object represents

Cluster-wide collector identity hosted through the cluster core-group ownership path. It gathers node/quorum/network/group/CSV summaries; Microsoft cluster objects remain authoritative for their own resource-level health.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Collect Cluster Shared Volume free space percent

HyperVPrivateCloud.Capability.Cluster.CSV.FreeSpacePercent.Collection.Rule

Collects the free space percentage of the fullest Cluster Shared Volume every 300 seconds. IntervalSeconds and TimeoutSeconds are overridable.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.FreeSpacePercent.Collection.Rule. Kind: Rule.

Alert versus health

Target=HyperVPrivateCloud.Capability.Cluster.ClusterRole; enabled=true; category=PerformanceCollection. Rules collect data or raise event alerts; they do not themselves create unit-monitor health transitions. Repeated or unresolved rule alerts do not by themselves explain a red DA. Correlate with current leaf monitors and event timestamps before closure.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Collect Cluster Shared Volume used space percent

HyperVPrivateCloud.Capability.Cluster.CSV.UsedSpacePercent.Collection.Rule

Collects the used space percentage of the fullest Cluster Shared Volume every 300 seconds. IntervalSeconds and TimeoutSeconds are overridable.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.UsedSpacePercent.Collection.Rule. Kind: Rule.

Alert versus health

Target=HyperVPrivateCloud.Capability.Cluster.ClusterRole; enabled=true; category=PerformanceCollection. Rules collect data or raise event alerts; they do not themselves create unit-monitor health transitions. Repeated or unresolved rule alerts do not by themselves explain a red DA. Correlate with current leaf monitors and event timestamps before closure.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Collect Cluster Shared Volume read latency

HyperVPrivateCloud.Capability.Cluster.CSV.ReadLatency.Collection.Rule

Collects the worst Cluster Shared Volume read latency in milliseconds every 300 seconds. IntervalSeconds and TimeoutSeconds are overridable.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.ReadLatency.Collection.Rule. Kind: Rule.

Alert versus health

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; category=PerformanceCollection. Rules collect data or raise event alerts; they do not themselves create unit-monitor health transitions. Repeated or unresolved rule alerts do not by themselves explain a red DA. Correlate with current leaf monitors and event timestamps before closure.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Collect Cluster Shared Volume write latency

HyperVPrivateCloud.Capability.Cluster.CSV.WriteLatency.Collection.Rule

Collects the worst Cluster Shared Volume write latency in milliseconds every 300 seconds. IntervalSeconds and TimeoutSeconds are overridable.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.WriteLatency.Collection.Rule. Kind: Rule.

Alert versus health

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; category=PerformanceCollection. Rules collect data or raise event alerts; they do not themselves create unit-monitor health transitions. Repeated or unresolved rule alerts do not by themselves explain a red DA. Correlate with current leaf monitors and event timestamps before closure.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Collect Cluster Shared Volume queue depth

HyperVPrivateCloud.Capability.Cluster.CSV.QueueDepth.Collection.Rule

Collects the worst Cluster Shared Volume I/O queue length every 300 seconds. IntervalSeconds and TimeoutSeconds are overridable.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.QueueDepth.Collection.Rule. Kind: Rule.

Alert versus health

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; category=PerformanceCollection. Rules collect data or raise event alerts; they do not themselves create unit-monitor health transitions. Repeated or unresolved rule alerts do not by themselves explain a red DA. Correlate with current leaf monitors and event timestamps before closure.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Show cluster summary

HyperVPrivateCloud.Capability.Cluster.Summary.Task

Cluster, quorum, node votes, networks and interfaces not Up, roles not Online, CSV state with free space, redirected access and fault state.

Summary

Show cluster summary

What it runs

Cluster, quorum, node votes, networks and interfaces not Up, roles not Online, CSV state with free space, redirected access and fault state.

Impact

Read-only. The task runs the query on the agent and returns text; it changes nothing.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Summary.Task. Kind: Task.

Execution safety

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; timeout=180. Read the task's original knowledge and parameters before execution. A Remediation task changes state and requires approval; do not execute it solely because the object is red. Even a diagnostic can generate logs or files; review its documented impact.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Generate the cluster log

HyperVPrivateCloud.Capability.Cluster.Log.Task

Get-ClusterLog for the last N minutes (Parameter, default 30) into ProgramData\HyperVPrivateCloud\ClusterLogs on every node.

Summary

Generate the cluster log

What it runs

Get-ClusterLog for the last N minutes (Parameter, default 30) into ProgramData\HyperVPrivateCloud\ClusterLogs on every node.

Impact

Read-only. The task runs the query on the agent and returns text; it changes nothing.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Log.Task. Kind: Task.

Execution safety

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; timeout=600. Read the task's original knowledge and parameters before execution. A Remediation task changes state and requires approval; do not execute it solely because the object is red. Even a diagnostic can generate logs or files; review its documented impact.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Validate cluster network (and S2D)

HyperVPrivateCloud.Capability.Cluster.Validate.Task

Test-Cluster -Include Network (and Storage Spaces Direct when enabled). Read-only but takes several minutes.

Summary

Validate cluster network (and S2D)

What it runs

Test-Cluster -Include Network (and Storage Spaces Direct when enabled). Read-only but takes several minutes.

Impact

Read-only. The task runs the query on the agent and returns text; it changes nothing.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Validate.Task. Kind: Task.

Execution safety

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; timeout=1800. Read the task's original knowledge and parameters before execution. A Remediation task changes state and requires approval; do not execute it solely because the object is red. Even a diagnostic can generate logs or files; review its documented impact.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Remediation: Move a CSV coordinator

HyperVPrivateCloud.Capability.Cluster.MoveCsvCoordinator.Task

Move-ClusterSharedVolume. Parameter = CSV resource name.

Summary

Move a CSV coordinator

What it runs

Move-ClusterSharedVolume. Parameter = CSV resource name.

Impact

This task changes the state of the target. The console asks for confirmation before it runs; use the read-only tasks first to confirm the diagnosis, and run it inside a change window where the environment requires one. The task output reports the resulting state.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.MoveCsvCoordinator.Task. Kind: Task.

Execution safety

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; timeout=300. Read the task's original knowledge and parameters before execution. A Remediation task changes state and requires approval; do not execute it solely because the object is red. Even a diagnostic can generate logs or files; review its documented impact.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Remediation: Drain this node

HyperVPrivateCloud.Capability.Cluster.DrainNode.Task

Suspend-ClusterNode -Drain (live migrates roles away). Parameter = node name (default: this node).

Summary

Drain this node

What it runs

Suspend-ClusterNode -Drain (live migrates roles away). Parameter = node name (default: this node).

Impact

This task changes the state of the target. The console asks for confirmation before it runs; use the read-only tasks first to confirm the diagnosis, and run it inside a change window where the environment requires one. The task output reports the resulting state.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.DrainNode.Task. Kind: Task.

Execution safety

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; timeout=1800. Read the task's original knowledge and parameters before execution. A Remediation task changes state and requires approval; do not execute it solely because the object is red. Even a diagnostic can generate logs or files; review its documented impact.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Remediation: Resume this node with failback

HyperVPrivateCloud.Capability.Cluster.ResumeNode.Task

Resume-ClusterNode -Failback Immediate. Parameter = node name (default: this node).

Summary

Resume this node with failback

What it runs

Resume-ClusterNode -Failback Immediate. Parameter = node name (default: this node).

Impact

This task changes the state of the target. The console asks for confirmation before it runs; use the read-only tasks first to confirm the diagnosis, and run it inside a change window where the environment requires one. The task output reports the resulting state.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.ResumeNode.Task. Kind: Task.

Execution safety

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; timeout=900. Read the task's original knowledge and parameters before execution. A Remediation task changes state and requires approval; do not execute it solely because the object is red. Even a diagnostic can generate logs or files; review its documented impact.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Remediation: Clear node quarantine

HyperVPrivateCloud.Capability.Cluster.ClearQuarantine.Task

Start-ClusterNode -ClearQuarantine. Parameter = node name (default: this node).

Summary

Clear node quarantine

What it runs

Start-ClusterNode -ClearQuarantine. Parameter = node name (default: this node).

Impact

This task changes the state of the target. The console asks for confirmation before it runs; use the read-only tasks first to confirm the diagnosis, and run it inside a change window where the environment requires one. The task output reports the resulting state.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.ClearQuarantine.Task. Kind: Task.

Execution safety

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; timeout=300. Read the task's original knowledge and parameters before execution. A Remediation task changes state and requires approval; do not execute it solely because the object is red. Even a diagnostic can generate logs or files; review its documented impact.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Remediation: Start a failed cluster role

HyperVPrivateCloud.Capability.Cluster.StartGroup.Task

Start-ClusterGroup. Parameter = role (group) name.

Summary

Start a failed cluster role

What it runs

Start-ClusterGroup. Parameter = role (group) name.

Impact

This task changes the state of the target. The console asks for confirmation before it runs; use the read-only tasks first to confirm the diagnosis, and run it inside a change window where the environment requires one. The task output reports the resulting state.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.StartGroup.Task. Kind: Task.

Execution safety

Target=HCSV2Library!HyperVPrivateCloud.HostRole; enabled=true; timeout=600. Read the task's original knowledge and parameters before execution. A Remediation task changes state and requires approval; do not execute it solely because the object is red. Even a diagnostic can generate logs or files; review its documented impact.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Failover Cluster integration pipeline health

HyperVPrivateCloud.Capability.Cluster.IntegrationHealth.Monitor

Verifies the FailoverClusters PowerShell prerequisite and the queries required to populate HCS service-impact relationships.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Availability.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Availability.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.IntegrationHealth.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

Checks the adapter query path used to connect HCS private-cloud objects to Microsoft Failover Cluster and CSV objects.

Operator response

Install RSAT-Clustering-PowerShell, verify HealthService permissions and cluster connectivity, confirm the Microsoft Cluster and CSV MPs are imported, then review Operations Manager events 8301 through 8303.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.IntegrationHealth.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.AvailabilityState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: (Property[@Name='ClusterIntegrationState'] = Good OR Property[@Name='ClusterIntegrationState'] = NotApplicable)

Warning [Warning]: Property[@Name='ClusterIntegrationState'] = Warning

Error [Critical]: Property[@Name='ClusterIntegrationState'] = Critical

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; IntervalSeconds=300; SyncTime=; TimeoutSeconds=120 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Error; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Cluster Shared Volume free space

HyperVPrivateCloud.Capability.Cluster.CSV.FreeSpace.Monitor

Measures the lowest percentage of free partition capacity among the collected Cluster Shared Volumes. The detail identifies the worst volume. Low free capacity threatens growth of VM disks, checkpoint chains and replication/backup files; the specific impact depends on the consumers and their disk behavior.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Performance.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Performance.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Performance.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Performance.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.CSV.FreeSpace.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

Measures the lowest percentage of free partition capacity among the collected Cluster Shared Volumes. The detail identifies the worst volume. Low free capacity threatens growth of VM disks, checkpoint chains and replication/backup files; the specific impact depends on the consumers and their disk behavior.

Causes

Actual data growth, dynamic virtual disks, checkpoint chains, backup retention or replication backlog can consume free space. A thin-provisioned array or storage pool can also have a separate capacity constraint not represented by CSV filesystem free percentage.

Resolution

Use the named CSV and owner to identify its consumers and compare filesystem, pool and array capacity. Arrange supported expansion or owner-approved workload/storage placement changes. Checkpoint cleanup must use supported Hyper-V or backup workflows with the chain and recovery implications reviewed; never manually delete AVHDX files. Investigate replication backlog rather than resetting replication merely because HRL files are large. Verify headroom and the latest monitor sample after the approved change.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.FreeSpace.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.PerformanceState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='CsvWorstFreePercent'] > 15

Warning [Warning]: (Property[@Name='CsvWorstFreePercent'] <= 15 AND Property[@Name='CsvWorstFreePercent'] > 8)

Error [Critical]: Property[@Name='CsvWorstFreePercent'] <= 8

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=8; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=CsvWorstFreePercent; SyncTime=; TimeoutSeconds=120; WarningThreshold=15 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Cluster Shared Volume redirected access

HyperVPrivateCloud.Capability.Cluster.CSV.RedirectedAccess.Monitor

Raises a warning when the count of Cluster Shared Volumes in redirected access mode reaches WarningThreshold (default 1) and an error at CriticalThreshold (default 2). Both thresholds are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Performance.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Performance.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Performance.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Performance.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.CSV.RedirectedAccess.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

One or more Cluster Shared Volumes are in redirected access mode, so all I/O from non-coordinator nodes is forwarded over the cluster network to the coordinator instead of going direct to storage. Redirected mode is expected briefly during backups and volume maintenance; sustained redirected mode degrades virtual machine storage performance on every non-coordinator node.

Causes

A backup application holding a CSV software snapshot (backup-induced redirected access).

Loss of direct storage connectivity from a node (SAN path, iSCSI session or S2D SBL failure) forcing redirected I/O for that node.

Filter drivers (antivirus, third-party replication, dedup) or ReFS volumes forcing file-system redirected mode.

Manual Suspend-ClusterResource or maintenance mode left in place.

Resolutions

Run Get-ClusterSharedVolumeState to see which nodes are redirected and the StateInfo reason (FileSystemRedirected vs BlockRedirected, backup, no direct IO).

For BlockRedirected, repair that node's storage connectivity (MPIO paths, iSCSI sessions, HBA links) then verify I/O returns to direct mode.

For backup-induced redirection, confirm the backup job completes; if it never clears, remove the orphaned CSV snapshot with the backup vendor procedure.

Threshold values are counts of redirected CSVs; raise CriticalThreshold only if a documented design uses persistent redirected mode.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.RedirectedAccess.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.PerformanceState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='CsvRedirectedCount'] < 1

Warning [Warning]: (Property[@Name='CsvRedirectedCount'] >= 1 AND Property[@Name='CsvRedirectedCount'] < 2)

Error [Critical]: Property[@Name='CsvRedirectedCount'] >= 2

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=2; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=CsvRedirectedCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=1 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Cluster Shared Volume offline or failed

HyperVPrivateCloud.Capability.Cluster.CSV.Offline.Monitor

Raises an error when the count of offline or failed Cluster Shared Volumes reaches CriticalThreshold (default 1). WarningThreshold defaults to 1 and both are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Availability.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Availability.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.CSV.Offline.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

At least one Cluster Shared Volume is offline or failed. Every virtual machine whose configuration or virtual hard disks live on that volume loses storage access and will be paused or fail.

Causes

The underlying storage (LUN, S2D virtual disk, SAN) is unavailable or was removed.

The Physical Disk resource failed after exhausting restart attempts (FailoverClustering events 1069/1205).

Volume corruption requiring chkdsk / ReFS repair, or the disk went read-only.

Administrative Stop-ClusterResource or maintenance not completed.

Resolutions

Get-ClusterSharedVolume and Get-ClusterResource -Name "Cluster Disk *" show the failed resource and owner; open the FailoverClustering-Manager and System event logs on that owner for the failure reason.

Restore storage presentation and paths, then Start-ClusterResource. For S2D, check Get-VirtualDisk and Get-StorageJob before bringing the CSV back.

Verify affected VMs (Get-VM | Where State -ne Running) and resume them once the volume is online.

This monitor is intended to alert on the first offline CSV; do not raise CriticalThreshold above 1 in production.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.Offline.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.AvailabilityState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='CsvOfflineCount'] < 1

Warning [Warning]: (Property[@Name='CsvOfflineCount'] >= 1 AND Property[@Name='CsvOfflineCount'] < 1)

Error [Critical]: Property[@Name='CsvOfflineCount'] >= 1

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Warning and critical thresholds are equal: this configuration has no intermediate numeric warning band. This can be intentional for discrete outages; do not claim an early warning is provided by this monitor.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=1; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=CsvOfflineCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=1 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Cluster Shared Volume paused

HyperVPrivateCloud.Capability.Cluster.CSV.Paused.Monitor

Raises a warning when the count of paused Cluster Shared Volumes reaches WarningThreshold (default 1) and an error at CriticalThreshold (default 2). Both thresholds are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Availability.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Availability.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.CSV.Paused.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

One or more Cluster Shared Volumes are paused. A paused CSV holds I/O while the cluster recovers the volume or the coordinator moves; if the pause persists, virtual machines on the volume stall and eventually pause with critical storage errors (FailoverClustering event 5120/5142).

Causes

Coordinator node failure or CSV ownership move in progress.

Storage latency or SMB/cluster-network interruption between nodes (event 5120 STATUS_IO_TIMEOUT / STATUS_CONNECTION_DISCONNECTED).

CSV filter or storage stack hang; excessive I/O on a single volume.

Resolutions

Check Get-ClusterSharedVolumeState and the FailoverClustering-CsvFs operational log on the coordinator for 5120/5142 events and their NT status codes.

Investigate cluster network health (Get-ClusterNetwork, Test-Cluster network tests) and storage latency on the coordinator.

If the pause does not clear within minutes, move the CSV coordinator (Move-ClusterSharedVolume) to a healthy node and check whether I/O resumes.

Threshold values are counts of paused CSVs.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.Paused.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.AvailabilityState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='CsvPausedCount'] < 1

Warning [Warning]: (Property[@Name='CsvPausedCount'] >= 1 AND Property[@Name='CsvPausedCount'] < 2)

Error [Critical]: Property[@Name='CsvPausedCount'] >= 2

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=2; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=CsvPausedCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=1 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Cluster Shared Volume read latency

HyperVPrivateCloud.Capability.Cluster.CSV.ReadLatency.Monitor

Raises a warning when the worst Cluster Shared Volume read latency reaches WarningThreshold milliseconds (default 25) and an error at CriticalThreshold milliseconds (default 50). Both thresholds are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Performance.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Performance.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Performance.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Performance.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.CSV.ReadLatency.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

The worst Cluster Shared Volume read latency across the cluster has reached the configured threshold in milliseconds. Sustained CSV read latency directly appears as guest disk latency inside every VM on that volume.

Causes

Storage array or S2D pool saturation, cache misses or a rebuild/resync job consuming IOPS.

Redirected access mode adding a network hop to every read.

A noisy-neighbour VM, backup or antivirus scan generating a read storm.

Degraded MPIO or iSCSI paths reducing effective bandwidth.

Resolutions

Correlate with the CSV performance views (Max Read Latency) and with the host physical disk latency monitors to see whether the array or the CSV layer is slow.

Identify top consumers with Get-StorageQoSFlow or Measure-VM / Hyper-V Virtual Storage Device counters and rebalance or throttle them (Storage QoS policies).

Check Get-ClusterSharedVolumeState for redirected access and repair direct I/O paths.

On all-flash storage lower WarningThreshold / CriticalThreshold; on hybrid or spinning media raise them to match the array design latency.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.ReadLatency.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.PerformanceState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='CsvMaxReadLatencyMs'] < 25

Warning [Warning]: (Property[@Name='CsvMaxReadLatencyMs'] >= 25 AND Property[@Name='CsvMaxReadLatencyMs'] < 50)

Error [Critical]: Property[@Name='CsvMaxReadLatencyMs'] >= 50

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=50; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=CsvMaxReadLatencyMs; SyncTime=; TimeoutSeconds=120; WarningThreshold=25 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Cluster Shared Volume write latency

HyperVPrivateCloud.Capability.Cluster.CSV.WriteLatency.Monitor

Raises a warning when the worst Cluster Shared Volume write latency reaches WarningThreshold milliseconds (default 25) and an error at CriticalThreshold milliseconds (default 50). Both thresholds are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Performance.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Performance.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Performance.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Performance.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.CSV.WriteLatency.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

The worst Cluster Shared Volume write latency across the cluster has reached the configured threshold in milliseconds. Write latency on a CSV is felt by every VM on the volume and is the most common cause of guest application timeouts.

Causes

Write cache exhausted or disabled on the array or S2D cache tier; mirror resync or repair in progress.

Redirected access mode forcing writes over the cluster network.

Backup, checkpoint merge or storage migration traffic on the volume.

Path degradation (MPIO, iSCSI, RDMA) reducing write bandwidth.

Resolutions

Review the CSV write-latency performance view and the S2D / SAN capability alerts raised at the same time.

Use Get-StorageQoSFlow or Hyper-V Virtual Storage Device counters to find the writer generating the load; move or throttle it.

Verify Get-ClusterSharedVolumeState shows direct I/O and that storage jobs (Get-StorageJob) are not running an unplanned repair.

Tune WarningThreshold / CriticalThreshold to the storage design latency; the defaults assume general-purpose hybrid storage.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.WriteLatency.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.PerformanceState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='CsvMaxWriteLatencyMs'] < 25

Warning [Warning]: (Property[@Name='CsvMaxWriteLatencyMs'] >= 25 AND Property[@Name='CsvMaxWriteLatencyMs'] < 50)

Error [Critical]: Property[@Name='CsvMaxWriteLatencyMs'] >= 50

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=50; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=CsvMaxWriteLatencyMs; SyncTime=; TimeoutSeconds=120; WarningThreshold=25 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Cluster Shared Volume queue depth

HyperVPrivateCloud.Capability.Cluster.CSV.QueueDepth.Monitor

Raises a warning when the worst Cluster Shared Volume I/O queue length reaches WarningThreshold (default 32) and an error at CriticalThreshold (default 64). Both thresholds are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Performance.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Performance.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Performance.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Performance.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.CSV.QueueDepth.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

The worst Cluster Shared Volume I/O queue length has reached the configured threshold. A sustained deep queue means the volume is receiving more I/O than the storage beneath it can service, and latency will follow.

Causes

Aggregate VM demand on a single CSV exceeding the LUN or virtual disk performance.

Storage rebuild, deduplication or backup job competing for the same spindles or SSDs.

Redirected access mode adding queueing at the coordinator.

Resolutions

Identify the CSV in the performance view, then list VMs on it (Get-VM | Get-VMHardDiskDrive | Where Path -like "<volume>").

Spread busy VMs across volumes with Move-VMStorage or apply Storage QoS limits to the offenders.

Confirm the array or S2D pool is healthy and not running an unplanned repair.

Thresholds are outstanding I/O counts; scale them with the number of spindles or the array queue depth.

Support scope

Cluster Shared Volume accessibility, capacity or I/O pressure, as observed by the cluster collector; worst-volume metrics summarize multiple CSVs.

Element: HyperVPrivateCloud.Capability.Cluster.CSV.QueueDepth.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.PerformanceState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='CsvMaxQueueDepth'] < 32

Warning [Warning]: (Property[@Name='CsvMaxQueueDepth'] >= 32 AND Property[@Name='CsvMaxQueueDepth'] < 64)

Error [Critical]: Property[@Name='CsvMaxQueueDepth'] >= 64

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=64; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=CsvMaxQueueDepth; SyncTime=; TimeoutSeconds=120; WarningThreshold=32 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterSharedVolume and inspect SharedVolumeInfo, owner, state and partition free space for each volume. Correlate redirected or paused access with backup activity, storage-path health, System events and CSV performance samples. Compare all nodes before assuming the coordinator is the failing storage device.

Corrective action and escalation

For unexpected redirection or offline storage, restore the failed storage/network dependency with the storage team. For low free space, stop unapproved growth and plan supported capacity expansion or owner-approved cleanup. Never delete VHDX/AVHDX files or force storage online as a generic alert response.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm every affected CSV is accessible from its intended nodes, expected direct access returns after maintenance, capacity headroom is restored, and latency stays below policy over a representative workload period.

Microsoft references

Microsoft Learn: failover cluster manage cluster shared volumes

Microsoft Learn: storage issues in hyper v and windows server failover clusters

Cluster node not up

HyperVPrivateCloud.Capability.Cluster.Node.Down.Monitor

Raises a warning when the count of cluster nodes that are not in the Up state reaches WarningThreshold (default 1) and an error at CriticalThreshold (default 2). Both thresholds are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Availability.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Availability.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Node.Down.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

One or more cluster nodes are not in the Up state (Down, Joining or Quarantined). Capacity and resilience are reduced; virtual machines that were on the node have failed over or are offline, and quorum may be at risk.

Causes

Unplanned host failure, reboot or power loss.

Cluster service stopped, or network isolation causing the node to be evicted from membership (FailoverClustering event 1135).

Node quarantined after repeatedly leaving and rejoining (event 1177/1200 series).

Planned maintenance where the node was not paused first.

Resolutions

Get-ClusterNode shows the node state; check the System and FailoverClustering-Manager logs on the affected node and the current coordinator (events 1135, 1177, 1146).

Restore the host, start the Cluster Service, or Start-ClusterNode -ClearQuarantine once the underlying network or hardware issue is fixed.

Verify VM placement afterwards (Get-ClusterGroup) and rebalance.

WarningThreshold is the first node down; CriticalThreshold defaults to 2 because losing two nodes usually threatens quorum or S2D resiliency.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Node.Down.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.AvailabilityState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='NodeDownCount'] < 1

Warning [Warning]: (Property[@Name='NodeDownCount'] >= 1 AND Property[@Name='NodeDownCount'] < 2)

Error [Critical]: Property[@Name='NodeDownCount'] >= 2

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=2; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=NodeDownCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=1 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Cluster node paused

HyperVPrivateCloud.Capability.Cluster.Node.Paused.Monitor

Raises a warning when the count of paused cluster nodes reaches WarningThreshold (default 1) and an error at CriticalThreshold (default 3). Both thresholds are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Configuration.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Configuration.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Configuration.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Configuration.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Node.Paused.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

One or more cluster nodes are paused. A paused node hosts no roles and is normally a deliberate maintenance state (Cluster-Aware Updating, patching, hardware work). Nodes left paused reduce capacity and, for S2D, delay repair jobs.

Causes

Planned maintenance (Suspend-ClusterNode, CAU run, drain) not yet resumed.

Failed drain-on-shutdown or CAU run that stopped mid-way.

S2D storage maintenance mode still enabled on the node.

Resolutions

Get-ClusterNode and Get-StorageFaultDomain -Type StorageScaleUnit show paused nodes and storage maintenance mode.

If maintenance is complete run Resume-ClusterNode -Failback Immediate and Disable-StorageMaintenanceMode where applicable.

Review the CAU run history if the pause was automated.

Thresholds are node counts; raise WarningThreshold if your patching design pauses more than one node at a time.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Node.Paused.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.ConfigurationState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='NodePausedCount'] < 2

Warning [Warning]: (Property[@Name='NodePausedCount'] >= 2 AND Property[@Name='NodePausedCount'] < 3)

Error [Critical]: Property[@Name='NodePausedCount'] >= 3

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=3; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=NodePausedCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=2 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Cluster quorum witness state

HyperVPrivateCloud.Capability.Cluster.Quorum.Witness.Monitor

Raises an error when the configured quorum witness resource is not online, that is when the witness failure count reaches CriticalThreshold (default 1). WarningThreshold defaults to 1 and both are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Availability.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Availability.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Quorum.Witness.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

The configured quorum witness (disk, file share or cloud witness) is not online. Without the witness, the cluster loses its tie-breaking vote and an even-node split or a further node loss can take the whole cluster offline.

Causes

File share witness server or share unavailable, permissions changed, or SMB signing/encryption mismatch.

Cloud witness storage account key rotated, expired or blocked by a proxy/firewall change.

Disk witness LUN unpresented or failed.

Witness resource failed repeatedly and was left offline (event 1069 for the witness resource).

Resolutions

Get-ClusterQuorum and Get-ClusterResource -Name "Witness" show the witness type and state; the FailoverClustering-Manager log gives the failure reason (1558/1562/1564 series).

Restore access to the witness share, storage account or LUN, then Start-ClusterResource on the witness.

For cloud witness rotate the key with Set-ClusterQuorum -CloudWitness -AccountName ... -AccessKey ....

This monitor should stay at CriticalThreshold 1; the witness is either available or not.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Quorum.Witness.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.AvailabilityState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='QuorumWitnessFailedCount'] < 1

Warning [Warning]: (Property[@Name='QuorumWitnessFailedCount'] >= 1 AND Property[@Name='QuorumWitnessFailedCount'] < 1)

Error [Critical]: Property[@Name='QuorumWitnessFailedCount'] >= 1

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Warning and critical thresholds are equal: this configuration has no intermediate numeric warning band. This can be intentional for discrete outages; do not claim an early warning is provided by this monitor.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=1; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=QuorumWitnessFailedCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=1 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Cluster quorum vote margin

HyperVPrivateCloud.Capability.Cluster.Quorum.VoteMargin.Monitor

Tracks how many further quorum votes may be lost before the cluster loses quorum. Raises a warning at or below WarningThreshold votes (default 2) and an error at or below CriticalThreshold votes (default 1). Both thresholds are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Availability.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Availability.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Quorum.VoteMargin.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

The cluster can lose only the reported number of further quorum votes before it loses quorum and stops. Vote margin counts current voting members (nodes plus witness) against the majority needed under dynamic quorum.

Causes

Nodes down or paused reducing the number of votes.

Witness offline (see the quorum witness monitor).

Dynamic quorum has already adjusted votes after previous failures; NodeWeight set to 0 on nodes by design or accident.

Resolutions

Get-ClusterNode | Select Name,State,NodeWeight,DynamicWeight and Get-ClusterQuorum show where votes were lost.

Restore failed nodes or the witness first; only then revisit NodeWeight settings.

Avoid maintenance on additional nodes while the margin is at the Warning value.

CriticalThreshold is pinned to 1 vote in every tuning tier because losing quorum is never a warning-level condition.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Quorum.VoteMargin.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.AvailabilityState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='QuorumVoteMarginCount'] > 0

Warning [Warning]: (Property[@Name='QuorumVoteMarginCount'] <= 0 AND Property[@Name='QuorumVoteMarginCount'] > -1)

Error [Critical]: Property[@Name='QuorumVoteMarginCount'] <= -1

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=-1; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=QuorumVoteMarginCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=0 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Cluster network partitioned

HyperVPrivateCloud.Capability.Cluster.Network.Partitioned.Monitor

Raises an error when the count of partitioned cluster networks reaches CriticalThreshold (default 1). WarningThreshold defaults to 1 and both are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Availability.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Availability.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Network.Partitioned.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

A cluster network is partitioned: some nodes can reach each other on it and others cannot. Partitioned networks break live migration, CSV redirected I/O and S2D SBL traffic and are a common precursor to node eviction.

Causes

Physical switch, VLAN or trunk misconfiguration affecting a subset of nodes.

NIC or SET team member failure on one or more nodes; RDMA/DCB misconfiguration.

Firewall or IPsec policy blocking cluster heartbeat (UDP 3343) between some nodes.

Network ATC intent drift or a node that missed a configuration update.

Resolutions

Get-ClusterNetwork and Get-ClusterNetworkInterface show which interfaces are Unreachable/Failed per node.

Test connectivity between the affected nodes on that subnet (Test-NetConnection, Test-Cluster -Include Network).

Repair the switch/VLAN/NIC fault; on Network ATC clusters run Get-NetIntentStatus and remediate the drifted host.

This monitor defaults to CriticalThreshold 1 partitioned network.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Network.Partitioned.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.AvailabilityState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='NetworkPartitionedCount'] < 1

Warning [Warning]: (Property[@Name='NetworkPartitionedCount'] >= 1 AND Property[@Name='NetworkPartitionedCount'] < 1)

Error [Critical]: Property[@Name='NetworkPartitionedCount'] >= 1

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Warning and critical thresholds are equal: this configuration has no intermediate numeric warning band. This can be intentional for discrete outages; do not claim an early warning is provided by this monitor.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=1; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=NetworkPartitionedCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=1 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Cluster network down

HyperVPrivateCloud.Capability.Cluster.Network.Down.Monitor

Raises a warning when the count of cluster networks in the Down state reaches WarningThreshold (default 1) and an error at CriticalThreshold (default 2). Both thresholds are overridable.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Availability.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Availability.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Network.Down.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

One or more cluster networks are in the Down state, meaning the cluster cannot use that network on any node. If it was a live-migration, storage or management network the corresponding traffic has failed over to another network or stopped.

Causes

Switch or uplink outage taking the whole subnet down.

The network's role was set to None and it is no longer used by the cluster (expected for isolated networks such as backup).

All NICs on that subnet disabled or unplugged during maintenance.

Resolutions

Get-ClusterNetwork shows the Down network and its role; Get-ClusterNetworkInterface shows the per-node interface state.

Restore the physical network and confirm interfaces return to Up.

If the network is intentionally unused, remove it from cluster use rather than leaving it Down, so this monitor reflects real faults.

Thresholds are counts of Down networks.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Network.Down.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.AvailabilityState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='NetworkDownCount'] < 1

Warning [Warning]: (Property[@Name='NetworkDownCount'] >= 1 AND Property[@Name='NetworkDownCount'] < 2)

Error [Critical]: Property[@Name='NetworkDownCount'] >= 2

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=2; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=NetworkDownCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=1 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Cluster role failure episodes

HyperVPrivateCloud.Capability.Cluster.Group.Failover.Monitor

Counts local role failure episodes from System provider Microsoft-Windows-FailoverClustering events 1069, 1205 and 1254 within FailoverWindowHours. Named ResourceGroup fields correlate resource failures with their owning role; each role/five-minute bucket counts once. This is an approximate retry/failure indicator, not a count of ownership changes, VM migrations or cluster failovers. Event 1177 is not included.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Availability.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Availability.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Group.Failover.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

Counts local role failure episodes from System provider Microsoft-Windows-FailoverClustering events 1069, 1205 and 1254 within FailoverWindowHours. Named ResourceGroup fields correlate resource failures with their owning role; each role/five-minute bucket counts once. This is an approximate retry/failure indicator, not a count of ownership changes, VM migrations or cluster failovers. Event 1177 is not included.

Causes

A resource can repeatedly fail without ever moving. Examples include a missing VM configuration path, an inaccessible storage dependency, or a Replica Broker network name that cannot create its AD computer object. A five-minute bucket is an aggregation policy, not an assertion that each bucket contains exactly one incident. Only events retained on the current collector node are counted; owner changes and log retention can change observed coverage.

Resolution

Use GroupDetail to identify the role, current owner, recent resource error and UTC evidence. Inspect the first failing dependency before considering recovery. Preserve configured identity and thresholds. After the cause is repaired, current resource health can recover before the rolling failure count drops below its thresholds.

Support scope

Clustered role failure and retry evidence. A role may contain several resources; locate the first failed dependency rather than treating every alert as a separate outage.

Element: HyperVPrivateCloud.Capability.Cluster.Group.Failover.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.AvailabilityState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='GroupFailoverEventCount'] < 3

Warning [Warning]: (Property[@Name='GroupFailoverEventCount'] >= 3 AND Property[@Name='GroupFailoverEventCount'] < 6)

Error [Critical]: Property[@Name='GroupFailoverEventCount'] >= 6

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=6; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=GroupFailoverEventCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=3 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

On the current owner, run Get-ClusterGroup and pipe the affected group to Get-ClusterResource. Read the local System log provider Microsoft-Windows-FailoverClustering, including 1069, 1194, 1205 and 1254. Match named ResourceGroup and ResourceName fields, timestamp and error code. For VM configuration failures, compare VmId with Get-VM on every possible owner and verify the configuration path exists.

Corrective action and escalation

Restore the specific missing dependency with its owning team. A Network Name creation failure needs the directory team to validate the cluster name account, destination container permissions, quota and any prestaged virtual computer object. A missing VM configuration needs backup/storage and VMM inventory reconciliation. Remove an orphaned role only after its owner confirms retirement and recoverability. Do not repeatedly restart a role or increase failover thresholds to hide the cause.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Verify resources and intended workloads are online, new failure events stop, and native and SCOM leaf states recover. Failure-window monitors can remain elevated until old episodes age out. An intentionally stopped VM or empty Available Storage group is not by itself evidence of a cluster outage.

Microsoft references

Microsoft Learn: prestage cluster adds

Microsoft Learn: hyper v start state access failures clustered standalone

Cluster role failed or partially online

HyperVPrivateCloud.Capability.Cluster.Group.Failed.Monitor

Counts cluster groups whose group-level state is Failed or PartialOnline. Offline is reported separately in detail and is not included in this count. A group can be Offline while one of its configuration resources is Failed; inspect native resource health and the Microsoft Cluster leaf monitors as well.

Representative root health path

Solution > HyperVPrivateCloud.Enterprise.Solution.Fabric.Availability.Dependency.Monitor > HyperVPrivateCloud.Enterprise.Fabric.Service.Availability.Dependency.Monitor > HyperVPrivateCloud.Service.Availability.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor > HyperVPrivateCloud.Capability.Cluster.Group.Failed.Monitor

This is one authored monitor path, not proof of current instance membership. Shared dependencies can have additional paths. Use Health Explorer to resolve the actual affected objects.

Summary

Counts cluster groups whose group-level state is Failed or PartialOnline. Offline is reported separately in detail and is not included in this count. A group can be Offline while one of its configuration resources is Failed; inspect native resource health and the Microsoft Cluster leaf monitors as well.

Causes

A dependent resource failed, a VM configuration or storage path is missing, or restart/failover attempts were exhausted. The parent group state alone does not identify which resource caused the problem.

Resolution

Run Get-ClusterGroup -Name <role> | Get-ClusterResource on a cluster node, inspect the failed resource and its first error, and coordinate the specific repair. Do not use the unsupported Get-ClusterResource -Group syntax. Starting a group changes workload state and requires owner approval. Verify intended resource and workload state afterwards.

Support scope

Clustered role failure and retry evidence. A role may contain several resources; locate the first failed dependency rather than treating every alert as a separate outage.

Element: HyperVPrivateCloud.Capability.Cluster.Group.Failed.Monitor. Kind: UnitMonitor.

Target and health path

Target class: HyperVPrivateCloud.Capability.Cluster.ClusterRole. Parent health aspect: Health!System.Health.AvailabilityState. Enabled by default: true. Follow this leaf through Health Explorer dependencies to identify which component and service inherit its state.

Why warning or critical

Success [Good]: Property[@Name='GroupFailedCount'] < 1

Warning [Warning]: (Property[@Name='GroupFailedCount'] >= 1 AND Property[@Name='GroupFailedCount'] < 1)

Error [Critical]: Property[@Name='GroupFailedCount'] >= 1

These are compiled default detection conditions, not effective overrides. For state-valued properties, the probe evaluates the condition described in the original knowledge above and supplies the actual cause in state-change context. NotApplicable is not a successful test of an absent capability.

Warning and critical thresholds are equal: this configuration has no intermediate numeric warning band. This can be intentional for discrete outages; do not claim an early warning is provided by this monitor.

Sampling and effective policy

Compiled configuration: BoundaryId=$Target/Property[Type="HyperVPrivateCloud.Capability.Cluster.ClusterRole"]/BoundaryId$; ComputerName=$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$; CriticalThreshold=1; FailoverWindowHours=24; IntervalSeconds=300; PropertyName=GroupFailedCount; SyncTime=; TimeoutSeconds=120; WarningThreshold=1 Check effective overrides before comparing a live value with these defaults. Interval is not persistence: do not assume consecutive samples or hysteresis unless explicitly configured. Increasing thresholds can conceal lost redundancy. Use customer-owned override packs, never the Default Management Pack.

Alert and recovery behavior

Alert starts at Warning; severity=MatchMonitorHealth; AutoResolve=true. A warning health state may be visible without a warning alert when AlertOnState is Error. Alert descriptions can retain the original incident details; compare the latest Health Explorer state-change context and a fresh diagnostic.

Read-only investigation

On the current owner, run Get-ClusterGroup and pipe the affected group to Get-ClusterResource. Read the local System log provider Microsoft-Windows-FailoverClustering, including 1069, 1194, 1205 and 1254. Match named ResourceGroup and ResourceName fields, timestamp and error code. For VM configuration failures, compare VmId with Get-VM on every possible owner and verify the configuration path exists.

Corrective action and escalation

Restore the specific missing dependency with its owning team. A Network Name creation failure needs the directory team to validate the cluster name account, destination container permissions, quota and any prestaged virtual computer object. A missing VM configuration needs backup/storage and VMM inventory reconciliation. Remove an orphaned role only after its owner confirms retirement and recoverability. Do not repeatedly restart a role or increase failover thresholds to hide the cause.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Verify resources and intended workloads are online, new failure events stop, and native and SCOM leaf states recover. Failure-window monitors can remain elevated until old episodes age out. An intentionally stopped VM or empty Available Storage group is not by itself evidence of a cluster outage.

Microsoft references

Microsoft Learn: prestage cluster adds

Microsoft Learn: hyper v start state access failures clustered standalone

Roll up Microsoft cluster health

HyperVPrivateCloud.Capability.Cluster.Availability.Cluster.Dependency.Monitor

Rolls up health from Microsoft cluster service objects into Availability and Clustering.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Availability.Cluster.Dependency.Monitor. Kind: DependencyMonitor.

Why warning or critical

Target=HCSV2Library!HyperVPrivateCloud.AvailabilityComponent; relationship=HyperVPrivateCloud.Capability.Cluster.AvailabilityContainsMicrosoftCluster; member monitor=Health!System.Health.AvailabilityState; parent=Health!System.Health.AvailabilityState; algorithm=WorstOf; unavailable-member policy=Success. The parent inherits the evaluated member state; it does not independently diagnose that member. Open the unhealthy member monitor to see the originating condition. Unavailable-member handling is not evidence of healthy telemetry and is distinct from an empty or unmonitored relationship.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Roll up Microsoft cluster node health

HyperVPrivateCloud.Capability.Cluster.Availability.Node.Dependency.Monitor

Rolls up health from Microsoft cluster node objects into Availability and Clustering.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Availability.Node.Dependency.Monitor. Kind: DependencyMonitor.

Why warning or critical

Target=HCSV2Library!HyperVPrivateCloud.AvailabilityComponent; relationship=HyperVPrivateCloud.Capability.Cluster.AvailabilityContainsMicrosoftClusterNode; member monitor=Health!System.Health.AvailabilityState; parent=Health!System.Health.AvailabilityState; algorithm=WorstOf; unavailable-member policy=Success. The parent inherits the evaluated member state; it does not independently diagnose that member. Open the unhealthy member monitor to see the originating condition. Unavailable-member handling is not evidence of healthy telemetry and is distinct from an empty or unmonitored relationship.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Roll up Microsoft cluster role health

HyperVPrivateCloud.Capability.Cluster.Availability.Group.Dependency.Monitor

Rolls up health from Microsoft cluster resource group objects into Availability and Clustering.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Availability.Group.Dependency.Monitor. Kind: DependencyMonitor.

Why warning or critical

Target=HCSV2Library!HyperVPrivateCloud.AvailabilityComponent; relationship=HyperVPrivateCloud.Capability.Cluster.AvailabilityContainsMicrosoftClusterGroup; member monitor=Health!System.Health.AvailabilityState; parent=Health!System.Health.AvailabilityState; algorithm=WorstOf; unavailable-member policy=Success. The parent inherits the evaluated member state; it does not independently diagnose that member. Open the unhealthy member monitor to see the originating condition. Unavailable-member handling is not evidence of healthy telemetry and is distinct from an empty or unmonitored relationship.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Roll up Microsoft cluster network health

HyperVPrivateCloud.Capability.Cluster.Availability.Network.Dependency.Monitor

Rolls up health from Microsoft cluster network objects into Availability and Clustering.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Availability.Network.Dependency.Monitor. Kind: DependencyMonitor.

Why warning or critical

Target=HCSV2Library!HyperVPrivateCloud.AvailabilityComponent; relationship=HyperVPrivateCloud.Capability.Cluster.AvailabilityContainsMicrosoftClusterNetwork; member monitor=Health!System.Health.AvailabilityState; parent=Health!System.Health.AvailabilityState; algorithm=WorstOf; unavailable-member policy=Success. The parent inherits the evaluated member state; it does not independently diagnose that member. Open the unhealthy member monitor to see the originating condition. Unavailable-member handling is not evidence of healthy telemetry and is distinct from an empty or unmonitored relationship.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Roll up Microsoft CSV health

HyperVPrivateCloud.Capability.Cluster.Storage.CSV.Dependency.Monitor

Rolls up health from Microsoft Cluster Shared Volume objects into Storage.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Storage.CSV.Dependency.Monitor. Kind: DependencyMonitor.

Why warning or critical

Target=HCSV2Library!HyperVPrivateCloud.StorageComponent; relationship=HyperVPrivateCloud.Capability.Cluster.StorageContainsMicrosoftClusterSharedVolume; member monitor=Health!System.Health.AvailabilityState; parent=Health!System.Health.AvailabilityState; algorithm=WorstOf; unavailable-member policy=Success. The parent inherits the evaluated member state; it does not independently diagnose that member. Open the unhealthy member monitor to see the originating condition. Unavailable-member handling is not evidence of healthy telemetry and is distinct from an empty or unmonitored relationship.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Roll up failover cluster availability into Availability and Clustering

HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor

Rolls up availability health of the failover cluster role into Availability and Clustering.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Availability.Dependency.Monitor. Kind: DependencyMonitor.

Why warning or critical

Target=HCSV2Library!HyperVPrivateCloud.AvailabilityComponent; relationship=HyperVPrivateCloud.Capability.Cluster.AvailabilityContainsClusterRole; member monitor=Health!System.Health.AvailabilityState; parent=Health!System.Health.AvailabilityState; algorithm=WorstOf; unavailable-member policy=Success. The parent inherits the evaluated member state; it does not independently diagnose that member. Open the unhealthy member monitor to see the originating condition. Unavailable-member handling is not evidence of healthy telemetry and is distinct from an empty or unmonitored relationship.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Roll up failover cluster performance into Availability and Clustering

HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Performance.Dependency.Monitor

Rolls up performance health of the failover cluster role into Availability and Clustering.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Performance.Dependency.Monitor. Kind: DependencyMonitor.

Why warning or critical

Target=HCSV2Library!HyperVPrivateCloud.AvailabilityComponent; relationship=HyperVPrivateCloud.Capability.Cluster.AvailabilityContainsClusterRole; member monitor=Health!System.Health.PerformanceState; parent=Health!System.Health.PerformanceState; algorithm=WorstOf; unavailable-member policy=Success. The parent inherits the evaluated member state; it does not independently diagnose that member. Open the unhealthy member monitor to see the originating condition. Unavailable-member handling is not evidence of healthy telemetry and is distinct from an empty or unmonitored relationship.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Roll up failover cluster configuration into Availability and Clustering

HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Configuration.Dependency.Monitor

Rolls up configuration health of the failover cluster role into Availability and Clustering.

Support scope

Cluster membership, quorum, witness, inter-node network or collector health. Loss of redundancy can precede an outage even while VMs remain running.

Element: HyperVPrivateCloud.Capability.Cluster.Availability.ClusterRole.Configuration.Dependency.Monitor. Kind: DependencyMonitor.

Why warning or critical

Target=HCSV2Library!HyperVPrivateCloud.AvailabilityComponent; relationship=HyperVPrivateCloud.Capability.Cluster.AvailabilityContainsClusterRole; member monitor=Health!System.Health.ConfigurationState; parent=Health!System.Health.ConfigurationState; algorithm=WorstOf; unavailable-member policy=Success. The parent inherits the evaluated member state; it does not independently diagnose that member. Open the unhealthy member monitor to see the originating condition. Unavailable-member handling is not evidence of healthy telemetry and is distinct from an empty or unmonitored relationship.

Read-only investigation

Run Get-ClusterNode, Get-ClusterQuorum and Get-ClusterNetwork locally on a cluster node. Identify paused versus down nodes, configured and current votes, witness state and partitioned networks. Review maintenance and the first cluster event. For collection errors, verify the supported Windows PowerShell runtime and FailoverClusters module before interpreting zero counts.

Corrective action and escalation

Restore the failed node, witness or network with the platform owner. Resume intentionally paused nodes only after maintenance is complete. Do not force quorum, change node weights or restart all nodes to clear a monitor. Repair collector access separately from workload health.

Capture object identity, owner, UTC timestamps, actual value/state, effective threshold, first error, relevant event IDs and recent changes. Escalate with that evidence when the cause remains uncertain. Disruptive or security-changing actions require the service owner and a recovery plan.

Verify recovery

Confirm expected membership, quorum resilience and network state, then verify fresh collector results and the originating monitor before the parent DA.

Microsoft references

Microsoft Learn: what is quorum witness

Microsoft Learn: quorum

Microsoft Learn: nf clusapi pauseclusternode

Microsoft Learn: failover cluster accounts overview

Microsoft Learn: hyper v cluster connectivity management configuration

Released under the MIT License.