NetApp ONTAP: Takeover Not Possible — Resolution Guide

An HA pair that cannot take over is a single point of failure wearing a disguise — the cluster looks healthy until the partner node fails, and then there is no failover path. NetApp's 'Takeover not possible' resolution guide maps every known reason to a specific fix, and this article walks that decision process: how to confirm the state, how to read the exact reason from storage failover show -instance, and what each cause means in practice. It applies to ONTAP 9 clusters (excluding MetroCluster IP).

The reason ONTAP is so insistent here is worth stating plainly: takeover transfers the partner's aggregates, LIFs and clients to the surviving node, and that copy depends on shared state — mailbox disks holding the partner's configuration, an NVRAM log that must be synchronised, and an HA interconnect that carries the in-flight writes. If any of those three is not in a trustworthy state, ONTAP refuses the takeover rather than risk split-brain or silent data loss. 'Takeover not possible' is therefore a protection mechanism, not a bug, and the correct response is always to find the reason before attempting any workaround.

Confirm Takeover Is Not Possible

::> storage failover show -node ClusterA-01 -fields possible
node          possible
------------- --------
ClusterA-01   false

The health of an HA pair is a property of both nodes, so check the pair rather than one node. The storage failover show table shows the takeover and giveback capability for each node in the pair, and the useful fields are takeov-possible, can-takeover, giveback-possible and takeover-state:

::> storage failover show
::> storage failover show -fields takeov-possible,takeover-state,giveback-possible
::> storage failover show-takeover

storage failover show-takeover is the underused command in this workflow. Instead of asking whether the partner can take over, it lists which resources would move and flags any that cannot, which usually points at the specific aggregate, LIF or disk set blocking the takeover before you dig into the reason string.

Find the Reason

::> storage failover show -instance -node <node_name>

The output includes the crucial line, for example:

Takeover Possible: false
Reason Takeover not Possible: Local node missing partner disks

Record the reason string exactly as printed. NetApp's resolution guide, the platform-specific KB articles and NetApp support all index the known failures by that string, and paraphrasing it ("it says something about disks") is the fastest way to receive the wrong procedure. If the field is empty while takeover still shows as impossible, re-run with -instance against both nodes — a node that is itself in an abnormal state can suppress the reason on the partner.

Decision Tree: Classify the Reason Before You Act

The reason strings fall into five groups, and the groups have very different risk profiles:

Configuration reasons are the ones you fix yourself in minutes. Everything else deserves a support case or at least a maintenance window, because the underlying state is either hardware or metadata that ONTAP is deliberately protecting.

Configuration-Related Reasons

The most common cause in practice is human: takeover was disabled for a maintenance activity and never re-enabled. ONTAP 9 replaced the old cf command family, so the current commands are:

::> storage failover show -fields enabled,auto-giveback
::> storage failover modify -node <node_name> -enabled true
::> storage failover modify -node <node_name> -auto-giveback true

Check both nodes in the pair — takeover enabled on node A but disabled on node B is a one-way HA configuration, and it will only fail in the direction nobody tested. A related case is a node that was halted after takeover was disabled: the partner cannot take over a halted node whose failover is still administratively off. Bring the node back to a normal state first, then re-enable and re-verify.

::> system node halt -node <node_name> -skip-lif-migration-before-shutdown true \
     -ignore-quorum-warnings true -inhibit-takeover true

That is the supported way to take a node down while deliberately keeping the partner from taking over — and every one of those flags has to be reversed afterwards, which is exactly the situation that produces this alert weeks later. Document the intent in the change record and re-check storage failover show at the end of the window.

Version and Upgrade-Related Reasons

During an ONTAP upgrade the nodes must run compatible versions, and takeover is refused while they do not. Confirm the running and installed images on both nodes:

::> system image show
::> cluster image show          // ONTAP releases before system image was introduced

A mismatch is usually a stalled or interrupted upgrade rather than an intentional state. Completing the upgrade is the fix; forcing the takeover instead is how an interrupted upgrade turns into a cluster-wide outage. If the upgrade cannot be completed immediately, the pair is running without HA protection, which is a risk worth recording explicitly rather than leaving implicit in a failed health check.

Mailbox and NVRAM Reasons

Mailbox disks and the NVRAM log are the shared-state foundation of an HA pair. The partner keeps its configuration in mailbox disks on shared storage, and the NVRAM log carries writes that have been acknowledged but not yet written to disk in a way that survives a node loss.

::> storage failover mailbox-disk show
::> storage failover show -instance -node <node_name>   // NVRAM log status

If the mailbox disk set is degraded, or the NVRAM log is reported as not synchronised, the takeover would move aggregates the partner cannot yet own correctly. Mailbox disk degradation is often a follow-on symptom of a shelf or disk problem, so treat it as a storage-health investigation rather than as an HA problem in isolation. When the mailbox disk set is damaged, the repair path involves reassigning the mailbox disks and may require NetApp support guidance for the platform — this is not a place for improvisation, because an incorrect mailbox assignment affects both nodes at once.

Disk Inventory and "Local Node Missing Partner Disks"

The reason string local node missing partner disks appears when a node cannot see the full set of disks that its partner owns, which means it cannot safely assume ownership of the partner's aggregates. Common underlying causes:

• A disk shelf was physically removed, powered off, or moved between stacks without updating ownership.
• Shelf cabling changes left one node with visibility of a shelf the other node lost.
• Disks were manually reassigned or removed during a prior maintenance activity.
• An ONTAP Select or CVO environment where the virtual disk inventory presented to the node changed.

::> storage disk show -ownership
::> storage disk show -container-type spare
::> storage shelf show

Compare the ownership output on both nodes: the disk set visible to each should be complementary, and any disk owned by the partner that this node cannot see explains the reason on its own. Restoring visibility is a cabling or environment task, not a cluster task — do the physical work first, then re-check storage failover show. Do not attempt to reassign disks as a shortcut to clearing the alert; ownership changes on the wrong set of disks can make the data unavailable on the next real takeover.

HA Interconnect Reasons

Interconnect errors and a down interconnect block takeover because HA depends on a dedicated, low-latency path between the nodes for the NVRAM log and the hardware-assisted takeover handshake. Verify the physical path and the adapter state before assuming a software problem: check cabling against the platform's HA interconnect ports, then look at node-level diagnostics:

::> system node run -node <node_name> -command sysconfig -v
::> system node run -node <node_name> -command sysconfig -A
::> event log show -severity alert

In ONTAP Select and CVO the equivalent evidence lives in the hypervisor and in the node's own event log — ONTAP Select reports a failed interconnect operation with a specific reason that maps back to the underlying virtual disk and network configuration, which is why the resolution guide splits these cases by platform. On AFF/FAS hardware, intermittent interconnect errors often precede a port or cable failure; treat them as a hardware warning rather than an HA decoration.

Environmental Reasons: Over-Temperature and Power

'Disk shelf being too hot' is easy to dismiss and worth taking seriously. ONTAP refuses to move a workload into an environment that is already in a thermal alarm condition, because the power or cooling fault responsible may affect both nodes of the pair. Check the alerts and the shelf environment before retrying:

::> system health alert show
::> storage shelf show -environment
::> system node environment show

Cooling, fan and power-supply faults are the ones that turn a routine takeover into a double failure: if both nodes share the same cooling enclosure or PDU, correcting the fault is more urgent than restoring the HA capability string.

Verify the Fix Without Dropping Service

Once the reason string clears, prove the fix rather than assuming it. Re-check both nodes, confirm the values, then exercise the path in a maintenance window:

::> storage failover show
::> storage failover show -fields takeov-possible,can-takeover
::> storage failover show-takeover
::> storage failover takeover -ofnode <partner_node>
::> storage failover giveback -ofnode <partner_node>
::> storage failover show

A controlled takeover and giveback in a window you chose is the only real confirmation that the pair would survive an unplanned failure. Watch the LIF migration and the aggregate online state during the exercise, and keep the storage failover show output before and after in the change record. If the reason reappears after giveback, it is usually the same underlying fault resurfacing and not a new one.

Common Causes and Fixes

Best Practice

Always confirm the reason before touching anything — forcing actions on a 'local node missing partner disks' state can cause data unavailability. For hardware-related reasons, verify with the appropriate hardware KB and contact NetApp support when the metadata needs cleanup.

Two habits prevent most recurrences. First, treat storage failover show as a scheduled check, not a response to an alert: a weekly sweep across every HA pair catches the operator-disabled and version-mismatch cases long before a real failure does. Second, whenever a change window requires disabling takeover, put the re-enable step in the same change record and verify it before closing the ticket — the majority of these alerts are caused by a window that ended without the pair being restored to full HA capability.

For the broader health picture, see responding to degraded ONTAP system health, monitoring ONTAP network port reachability and the ONTAP port troubleshooting resolution guide.

原文链接：https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/Takeover_not_possible_resolution_guide