Manual giveback commands

11/04/2024 Contributors

You can perform a normal giveback, a giveback in which you terminate processes on the partner node, or a forced giveback.

Prior to performing a giveback, you must remove the failed drives in the taken-over system as described in Disks and aggregates management.

If giveback is interrupted

If the takeover node experiences a failure or a power outage during the giveback process, that process stops and the takeover node returns to takeover mode until the failure is repaired or the power is restored.

However, this depends upon the stage of giveback in which the failure occurred. If the node encountered failure or a power outage during partial giveback state (after it has given back the root aggregate), it will not return to takeover mode. Instead, the node returns to partial-giveback mode. If this occurs, complete the process by repeating the giveback operation.

If giveback is vetoed

If giveback is vetoed, you must check the EMS messages to determine the cause. Depending on the reason or reasons, you can decide whether you can safely override the vetoes.

The storage failover show-giveback command displays the giveback progress and shows which subsystem vetoed the giveback, if any. Soft vetoes can be overridden, while hard vetoes cannot be, even if forced. The following tables summarize the soft vetoes that should not be overridden, along with recommended workarounds.

You can review the EMS details for any giveback vetoes by using the following command:

event log show -node * -event gb*

Giveback of the root aggregate

These vetoes do not apply to aggregate relocation operations:

Vetoing subsystem module	Workaround
vfiler_low_level	Terminate the SMB sessions causing the veto, or shutdown the SMB application that established the open sessions. Overriding this veto might cause the application using SMB to disconnect abruptly and lose data.
Disk Check	All failed or bypassed disks should be removed before attempting giveback. If disks are sanitizing, you should wait until the operation completes. Overriding this veto might cause an outage caused by aggregates or volumes going offline due to reservation conflicts or inaccessible disks.

Vetoing subsystem module

Workaround

vfiler_low_level

Terminate the SMB sessions causing the veto, or shutdown the SMB application that established the open sessions.

Overriding this veto might cause the application using SMB to disconnect abruptly and lose data.

Disk Check

All failed or bypassed disks should be removed before attempting giveback. If disks are sanitizing, you should wait until the operation completes.

Overriding this veto might cause an outage caused by aggregates or volumes going offline due to reservation conflicts or inaccessible disks.

Giveback of the SFO aggregates

These vetoes do not apply to aggregate relocation operations:

Vetoing subsystem module	Workaround
Lock Manager	Gracefully shutdown the SMB applications that have open files, or move those volumes to a different aggregate. Overriding this veto results in loss of SMB lock state, causing disruption and data loss.
Lock Manager NDO	Wait until the locks are mirrored. Overriding this veto causes disruption to Microsoft Hyper-V virtual machines.
RAID	Check the EMS messages to determine the cause of the veto: If the veto is due to nvfile, bring the offline volumes and aggregates online. If disk add or disk ownership reassignment operations are in progress, wait until they complete. If the veto is due to an aggregate name or UUID conflict, troubleshoot and resolve the issue. If the veto is due to mirror resync, mirror verify, or offline disks, the veto can be overridden and the operation restarts after giveback.
Disk Inventory	Troubleshoot to identify and resolve the cause of the problem. The destination node might be unable to see disks belonging to an aggregate being migrated. Inaccessible disks can result in inaccessible aggregates or volumes.
Volume Move Operation	Troubleshoot to identify and resolve the cause of the problem. This veto prevents the volume move operation from aborting during the important cutover phase. If the job is aborted during cutover, the volume might become inaccessible.

Vetoing subsystem module

Workaround

Lock Manager

Gracefully shutdown the SMB applications that have open files, or move those volumes to a different aggregate.

Overriding this veto results in loss of SMB lock state, causing disruption and data loss.

Lock Manager NDO

Wait until the locks are mirrored.

Overriding this veto causes disruption to Microsoft Hyper-V virtual machines.

RAID

Check the EMS messages to determine the cause of the veto:

If the veto is due to nvfile, bring the offline volumes and aggregates online.

If disk add or disk ownership reassignment operations are in progress, wait until they complete.

If the veto is due to an aggregate name or UUID conflict, troubleshoot and resolve the issue.

If the veto is due to mirror resync, mirror verify, or offline disks, the veto can be overridden and the operation restarts after giveback.

Disk Inventory

Troubleshoot to identify and resolve the cause of the problem.

The destination node might be unable to see disks belonging to an aggregate being migrated.

Inaccessible disks can result in inaccessible aggregates or volumes.

Volume Move Operation

Troubleshoot to identify and resolve the cause of the problem.

This veto prevents the volume move operation from aborting during the important cutover phase. If the job is aborted during cutover, the volume might become inaccessible.

Commands for performing a manual giveback

You can manually initiate a giveback on a node in an HA pair to return storage to the original owner after completing maintenance or resolving
any issues that caused the takeover.

If you want to…	Use this command…
Give back storage to a partner node	`storage failover giveback ‑ofnode nodename`
Give back storage even if the partner is not in the waiting for giveback mode	`storage failover giveback ‑ofnode nodename` `‑require‑partner‑waiting false` Do not use this option unless a longer client outage is acceptable.
Give back storage even if processes are vetoing the giveback operation (force the giveback)	`storage failover giveback ‑ofnode nodename` `‑override‑vetoes true` Use of this option can potentially lead to longer client outage, or aggregates and volumes not coming online after the giveback.
Give back only the CFO aggregates (the root aggregate)	`storage failover giveback ‑ofnode nodename` `‑only‑cfo‑aggregates true`
Monitor the progress of giveback after you issue the giveback command	`storage failover show‑giveback`

If you want to…

Use this command…

Give back storage to a partner node

storage failover giveback ‑ofnode nodename

Give back storage even if the partner is not in the waiting for giveback mode

storage failover giveback ‑ofnode nodename
‑require‑partner‑waiting false

Do not use this option unless a longer client outage is acceptable.

Give back storage even if processes are vetoing the giveback operation (force the giveback)

storage failover giveback ‑ofnode nodename
‑override‑vetoes true

Use of this option can potentially lead to longer client outage, or aggregates and volumes not coming online after the giveback.

Give back only the CFO aggregates (the root aggregate)

storage failover giveback ‑ofnode nodename

‑only‑cfo‑aggregates true

Monitor the progress of giveback after you issue the giveback command

storage failover show‑giveback