Manual giveback commands

Contributors Download PDF of this page

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

Note Prior to performing a giveback, you must remove the failed drives in the taken-over system as described in the Disks and Aggregates Power Guide.

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 CIFS sessions causing the veto, or shutdown the CIFS application that established the open sessions.

Overriding this veto might cause the application using CIFS 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 CIFS applications that have open files, or move those volumes to a different aggregate.

Overriding this veto results in loss of CIFS 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