ONTAP HA: Automatic Takeover, Giveback and Aggregate Policies

Automatic operation and timing

Takeover and giveback work together to limit client interruption. With the applicable default HA settings, a partner can take over after a panic, reboot, halt or unresponsive-node event, then return storage when the affected node is ready. Confirm the actual release and HA configuration; a default description is not a promise that every failure or client protocol is nondisruptive.

The source shows this ordinary automatic-giveback control:

storage failover modify -auto-giveback false -node <node>

Use the actual node name. Other triggers have independent controls, including panic-specific and onreboot behavior; the setting above alone does not disable every automatic-giveback path. The delay option is -delay-seconds, correcting the broken “-delay- seconds” text. The source gives a 600-second default. Delaying giveback separates takeover and giveback outages instead of combining takeover, node boot and giveback into one long interruption.

The source says a failed non-root aggregate giveback gets two additional automatic attempts. Its timer starts before the partner is ready; if it expires too soon it restarts. Consequently, the time from readiness to actual giveback can be shorter than a full configured delay.

What happens during takeover

For a user-initiated negotiated takeover, non-root aggregate ownership/control is relocated in sequence to reduce interruption. Each relocation can cause a short I/O pause.
The target then shuts down gracefully and its root aggregate, plus any remaining aggregates, are taken over.
Data LIFs move according to their failover rules. In a negotiated operation they can move before storage takeover; after panic/failure the timing depends on configuration.
The takeover node continues serving/updating the partner’s aggregates and volumes.

A panic does not permit the same negotiated preparation. Lost inter-node communication/heartbeat can trigger failure detection, with additional delay while the surviving partner detects the loss. No heartbeat timeout value is invented here.

Monitor the storage takeover with:

storage failover show-takeover

The source names storage failover takeover -bypass-optimization to bypass aggregate relocation and -skip-lif-migration to skip LIF migration for an applicable operation. These are option references, not complete commands to paste. Bypassing the negotiated optimization can increase interruption; use the exact release’s procedure.

SMB client impact

Existing SMB sessions can disconnect. SMB1/SMB2.x cannot preserve open file handles across takeover in the same way as supported SMB3 continuously available shares, so interruption and loss of uncommitted work are possible. Supported SMB3 clients/shares configured for Continuous Availability can reconnect persistent handles; the source specifically mentions Hyper-V. Check the complete client/share/application prerequisites rather than assuming all SMB3 sessions are protected.

If the takeover node itself panics early

For the source’s case where it panics within 60 seconds of starting takeover, the node reboots, performs self-recovery and leaves takeover mode, with failover disabled. After resolving the fault and restoring supported storage failover, any partner aggregates still held by that node must be returned using the appropriate storage failover giveback procedure. Do not reenable HA or force ownership based only on this abbreviated scenario.

Normal giveback sequence

Resolve the underlying issue on node B, which was taken over by node A. B reaches Waiting for giveback.
Start the supported giveback manually or through the configured automatic path.
A returns B’s root aggregate first so B can complete booting.
After B can accept non-root aggregates and its management services are online, A returns the remaining aggregates one at a time. I/O resumes for each returned aggregate.

storage failover show-giveback
storage failover show

show-giveback reports aggregate giveback progress but does not describe every recovery operation. The general show command adds current readiness, takeover capability and recovery-state information.

CFO and SFO are aggregate HA policies

In this source model, root aggregates use CFO (controller failover); non-root aggregates use SFO (storage failover). SFO aggregates support sequential aggregate relocation and delayed sequential return after the target is ready. Root/CFO aggregate return happens first to enable boot. Although people sometimes use the terms loosely for an HA operation, they describe aggregate policies here.

Changing an aggregate’s HA policy is a maintenance-mode operation and must not be done without the matching support instruction.

Background disk-firmware update interactions

A manual takeover can wait for a background drive-firmware update on either node. If that wait exceeds the source’s 120-second limit, the operation aborts and must be restarted after the update completes.
The source says -bypass-optimization true avoids the destination-update dependency in its documented takeover path.
A manual immediate takeover (-options immediate) starts immediately for the described source/takeover-node update scenario.
A panic-triggered takeover begins immediately despite a background update on the failed node.
Data-aggregate giveback can wait for firmware work on either node and abort after the stated 120-second wait.
Aggregate relocation has the same documented wait/abort behavior; the source’s -override-destination-checks true exception concerns updates on the destination.

Those options bypass preparation/checks and are not routine remedies for slow firmware updates. Confirm operation, source/destination roles and current command semantics before use.