Replace a NetApp FAS8200 Controller: Hardware Transfer and System Recovery

This guide translates the stored FAS8200 controller-replacement procedure and preserves its component diagrams and example command output. NetApp publishes corresponding English chapters, linked below. Choose the procedure matching the actual ONTAP release and HA or MetroCluster configuration. Example node names and system IDs identify separate examples; substitute verified values for the real system.

1. Requirements and controller roles

All drive shelves must be working. If V_StorageAttach is licensed, review its additional replacement requirements first.
For an HA pair, the healthy controller must be capable of taking over the impaired controller. For MetroCluster, first use the linked recovery-selection guidance. When this procedure applies, four- or eight-controller MetroCluster replacement follows the HA-pair path; the special two-node MetroCluster branch is separate.
Use the provider’s replacement FRU of the same controller model. This procedure does not upgrade a system and does not replace drives or shelves.
Move the existing boot device so the replacement starts the same ONTAP version. Verify that the replacement supports every transferred PCIe card using NetApp Hardware Universe.
Impaired means the old controller being replaced; replacement means the new module; healthy means the surviving controller (the DR partner in the two-node MetroCluster branch). Run each command on the stated controller.
Capture console output to a text log throughout the procedure for recovery and troubleshooting.

2. Shut down the impaired controller

2.1 Most systems

For SAN, check SCSI-blade events with cluster kernel-service show at advanced privilege. The processes must be in quorum with the other nodes. A cluster with more than two nodes must also have quorum. Resolve eligibility, health or quorum problems before proceeding; use the linked node-synchronization guidance where needed.

If AutoSupport is enabled, suppress automatic case creation for the maintenance window without disabling diagnostic reporting. The source’s two-hour example is:

system node autosupport invoke -node * -type all -message MAINT=2h

Disable automatic giveback from the healthy controller and confirm the prompt with y. The current NetApp English chapter targets local from that console:

storage failover modify -node local -auto-giveback false

The stored source used impaired_node_name in that command. Verify the intended node against the release-specific procedure rather than mixing old and new targeting instructions.

If the impaired controller is already at LOADER, continue with the applicable replacement path.
If it is Waiting for giveback, press Ctrl-C and answer y when prompted.
If it is at a system or password prompt, take it over and halt it from the healthy controller:

storage failover takeover -ofnode impaired_node_name -halt true

The -halt true argument leaves the impaired controller at LOADER.

2.2 Two-node MetroCluster only

Keep power available to the healthy controller. Use metrocluster show to establish whether switchover already occurred. If so, continue; otherwise perform metrocluster switchover from the surviving side. Resolve veto messages and retry only as appropriate; if they cannot be resolved, contact support.

Resynchronize the data aggregates, verify the operation and inspect aggregate state:

controller_A_1::> metrocluster heal -phase aggregates
[Job 130] Job succeeded: Heal Aggregates is successful.

controller_A_1::> metrocluster operation show
    Operation: heal-aggregates
      State: successful
Start Time: 7/25/2016 18:45:55
   End Time: 7/25/2016 18:45:56
     Errors: -

controller_A_1::> storage aggregate show
Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
--------- -------- --------- ----- ------- ------ ---------------- ------------
...
aggr_b2    227.1GB   227.1GB    0% online       0 mcc1-a2          raid_dp, mirrored, normal...

Heal the root aggregates and verify that operation too:

mcc1A::> metrocluster heal -phase root-aggregates
[Job 137] Job succeeded: Heal Root Aggregates is successful

mcc1A::> metrocluster operation show
  Operation: heal-root-aggregates
      State: successful
 Start Time: 7/29/2016 20:54:41
   End Time: 7/29/2016 20:54:42
     Errors: -

The source describes -override-vetoes for soft heal vetoes. Review the specific veto and the applicable recovery procedure before using an override; it is not a general instruction to bypass every veto. After the required heal operations complete, disconnect power to the impaired module as instructed for that configuration.

3. Move the controller hardware

3.1 Remove and open the impaired module

Ground yourself. Release the cable-management straps, label/track connections, and disconnect system cables and SFPs as needed. Leave cables organized in the management devices.
Remove the left and right cable-management devices. Move any SFPs left in the old module to the replacement.
Loosen the cam-handle thumbscrew, lower the cam handle and slide the module out while supporting its underside.

Original language-neutral cable-management-arm removal diagram

Original cam-handle and thumbscrew diagram

Thumbscrew; cam handle.

3.2 Move the boot device

Locate the boot media using the diagram or FRU map. Press the blue release button, then gently withdraw it straight out of its socket:

Original language-neutral boot-media removal and insertion diagram

Do not twist the boot media or pull it vertically upward; the socket or media can be damaged.

Align the media with the replacement module’s socket and insert it gently. Check that it is square and fully seated; reseat if needed. Push it down to engage the housing’s locking button.

3.3 Remove the NVMEM battery for transfer

Check the NVMEM LED. In an HA configuration, follow the HA procedure to the next step. For a stand-alone system, perform a clean shutdown and check the NVRAM LED identified by the NV symbol:

During halt, the LED blinks while NVRAM contents destage to flash, then turns off. After an unclean power loss it also flashes until destaging completes. A lit LED with power on indicates unwritten NVMEM data; do not treat that state as completed destaging.

Open the CPU air duct. Press the blue battery tab marked PUSH, lift the battery from its holder and set it aside for transfer after the DIMMs:

Original language-neutral NVMEM battery diagram

Battery lock tab; NVMEM battery pack.

3.4 Transfer the DIMMs, then reinstall the battery

Record each DIMM’s slot and orientation. Open both ejector tabs slowly and slide the DIMM out. The number and positions vary by model:

Hold DIMMs by their edges without pressing the circuit-board components.

Original language-neutral DIMM transfer diagram

At the corresponding replacement slot, open the ejectors and insert the DIMM squarely. It fits tightly but should enter without forcing; realign and retry if it does not.

Inspect every DIMM for even alignment and full seating.

Repeat for all DIMMs. Transfer the NVMEM battery: align the holder tabs with the module notches, then press the housing down gently until it clicks into place.

3.5 Transfer the PCIe cards

Prepare the replacement so cards can move directly into their corresponding slots. Loosen the side-panel thumbscrew and swing the panel open. Remove each card, recording its original slot:

Original language-neutral PCIe card and side-panel diagram

Side panel; PCIe card.

Open the replacement side panel and remove fillers as necessary. Align each supported card with its matching slot and apply even pressure until it is fully and evenly seated. Repeat for the remaining cards. Close the panel and tighten its thumbscrew.

3.6 Transfer the cache module or modules

Locate the cache assembly at the rear. Press its release tab and remove the heat sink. The source describes two cache slots, with one populated by default:

Original language-neutral cache-module and heat-sink diagram

Align the cache module with the replacement socket, insert it gently and verify full, square seating. Reseat if needed. Refit and press the heat sink down to engage its locking mechanism. Repeat for a second cache module if present, then close the module cover.

3.7 Install and boot the replacement

Firmware may update during boot. Do not interrupt an active firmware update; wait until it completes before interrupting the ordinary boot sequence.

Ground yourself and close the CPU air duct. Align the module and slide it halfway into the chassis. Connect management and console ports so you can perform the configuration steps; other connections follow later.

Do not seat the module fully until the applicable procedure calls for it.

The source and matching NetApp chapter describe system-ID mismatch and HA Maintenance-mode confirmation prompts. Answer y only in the verified replacement sequence for the correct controller roles; do not turn a generic prompt into an instruction to shut down the surviving controller.

HA pair: With the cam handle open, seat the module against the midplane, close and lock the handle, and tighten its thumbscrew. The module starts booting as soon as it is fully seated.

Do not force the module into the chassis; the connectors can be damaged.

Reinstall cable management and straps. At Press Ctrl-C for Boot Menu, press Ctrl-C, then choose Maintenance mode.

If the module reaches ONTAP because the prompt was missed, use halt, then boot_ontap at LOADER; interrupt at the prompt and choose Maintenance mode. Wait for any firmware update first.

Stand-alone: Seat the module with the cam handle open, lock the handle, tighten the thumbscrew and restore cable management.

Do not use excessive insertion force.

Reconnect the power supplies and power sources as required, turn on power, interrupt at the Ctrl-C boot-menu prompt and select Maintenance mode.

If the prompt was missed and ONTAP started, halt to LOADER, run boot_ontap and interrupt at the next boot-menu prompt before choosing Maintenance mode.

4. Restore and verify low-level configuration

4.1 Verify date and time

Compare the replacement with the healthy HA node or a reliable time source for a stand-alone system. At the healthy node, cluster date show uses its configured time zone. At the replacement LOADER prompt, show date reports GMT. If necessary, set the replacement’s GMT date and time, then verify again:

set date mm/dd/yyyy
set time hh:mm:ss
show date

4.2 Verify HA state

In Maintenance mode on the replacement, run ha-config show. Component HA states must match the actual configuration. If the controller state needs correction, use ha-config modify controller ha-state with the appropriate value: ha, mcc, mcc-2n, mccip or non-ha. Verify again with ha-config show.

5. Recable and verify disk ownership

5.1 Verify storage and network cabling

Use the linked Active IQ Config Advisor. Enter the target system details and collect data. In Cabling, verify that every shelf and disk appears and correct detected cabling issues. Review the other relevant tabs for the remaining connections.

5.2 HA-pair system-ID confirmation and giveback

This branch applies to ONTAP HA pairs. From replacement Maintenance mode, halt to LOADER and run boot_ontap; confirm the intended system-ID replacement when prompted. Wait for Waiting for giveback. On the healthy controller, storage failover show should report the expected old and new partner IDs. This source example changes node2 from 151759755 to 151759706:

node1> `storage failover show`
                                    Takeover
Node              Partner           Possible     State Description
------------      ------------      --------     -------------------------------------
node1             node2             false        System ID changed on partner (Old:
                                                  151759755, New: 151759706), In takeover
node2             node1             -            Waiting for giveback (HA mailboxes)

On the healthy controller, enter advanced privilege with set -privilege advanced. If Storage or Volume Encryption is configured, restore its functionality using the linked onboard or external key-management procedure. Do not put actual recovery keys into this documentation. Save outstanding cores and wait for completion before giveback:

system node run -node local-node-name partner savecore
system node run -node local-node-name partner savecore -s
set -privilege admin

The second command checks savecore progress. Return to admin privilege, then issue giveback from the healthy controller for the verified replacement:

storage failover giveback -ofnode replacement_node_name

The replacement regains its storage and finishes booting. Confirm the intended system-ID change if prompted.

If giveback is vetoed, review the veto and the ONTAP-version-specific HA instructions before considering an override.

After completion, storage failover show must show healthy HA operation and takeover capability, without the old System ID changed on partner message. Verify disk ownership using storage disk show -ownership. The next source output is a separate example using new ID 1873775277, not a continuation of the preceding node2 IDs:

node1> `storage disk show -ownership`

Disk  Aggregate Home  Owner  DR Home  Home ID    Owner ID  DR Home ID Reserver  Pool
----- ------    ----- ------ -------- -------    -------    -------  ---------  ---
1.0.0  aggr0_1  node1 node1  -        1873775277 1873775277  -       1873775277 Pool0
1.0.1  aggr0_1  node1 node1           1873775277 1873775277  -       1873775277 Pool0
.
.
.

5.3 Two-node MetroCluster manual reassignment

Use this separate branch only for two-node MetroCluster. Boot the replacement to Maintenance mode and confirm the intended ID override. On the healthy DR partner, obtain the old IDs with metrocluster node show -fields node-systemid,dr-partner-systemid. The old Node_B_1 ID in the source is 118073209:

dr-group-id cluster         node                 node-systemid dr-partner-systemid
 ----------- --------------------- -------------------- ------------- -------------------
 1           Cluster_A             Node_A_1             536872914     118073209
 1           Cluster_B             Node_B_1             118073209     536872914
 2 entries were displayed.

On the replacement in Maintenance mode, disk show reports its new local system ID, 118065481 in this example:

Local System ID: 118065481
    ...
    ...

For the illustrated FAS procedure, reassign from the verified old ID and confirm when prompted. The example uses:

disk reassign -s 118073209

Use disk show -a to verify the replacement-owned disks now carry the new ID:

*> disk show -a
Local System ID: 118065481

  DISK     OWNER                 POOL   SERIAL NUMBER  HOME
-------    -------------         -----  -------------  -------------
disk_name   system-1  (118065481) Pool0  J8Y0TDZC       system-1  (118065481)
disk_name   system-1  (118065481) Pool0  J8Y09DXC       system-1  (118065481)
.
.
.

On the healthy controller, use advanced privilege to save/verify outstanding cores with system node run -node local-node-name partner savecore, monitor with the same command plus -s and wait for completion. Return to admin privilege. Halt the replacement from Maintenance mode to LOADER, then boot it with boot_ontap. Perform the applicable switchback only after the replacement is fully booted and the recovery preconditions below are satisfied.

Verify configuration with metrocluster node show -fields configuration-state. The source’s following output is another configuration example, with four listed nodes:

node1_siteA::> metrocluster node show -fields configuration-state

dr-group-id            cluster node           configuration-state
-----------            ---------------------- -------------- -------------------
1 node1_siteA          node1mcc-001           configured
1 node1_siteA          node1mcc-002           configured
1 node1_siteB          node1mcc-003           configured
1 node1_siteB          node1mcc-004           configured

4 entries were displayed.

Check system health alert show on both clusters, metrocluster show, metrocluster check run and metrocluster check show. Run Config Advisor and resolve its findings. The source also includes a simulated switchover, not a switchback:

set -privilege advanced
metrocluster switchover -simulate
set -privilege admin

6. Complete recovery

6.1 Restore replacement-controller licensing

For older standard node-locked feature licenses, each node needs its appropriate replacement entitlement. The source describes temporary continued feature availability but restricts configuration changes when the impaired node held the only entitlement. Obtain replacement licensing promptly; temporary availability does not establish license compliance.

For that legacy 28-character-key workflow, the source describes a 90-day grace period and a 24-hour window to install all keys after the first valid replacement key is installed. Do not apply those legacy rules to every ONTAP licensing format.

If the system initially ran ONTAP 9.10.1 or later, use the linked post-motherboard-replacement licensing procedure. If the initial release is uncertain, check Hardware Universe and support records.

Obtain required replacement entitlements from NetApp Support under My Support → Software licenses.

The archived source and matching English chapter say generated keys are sent to the registered email address and to contact support if no email arrives within 30 days. Confirm the actual entitlement and delivery with support rather than delaying necessary licensing action.

Install the appropriate key through the documented system license add -license-code workflow. Actual license keys are deliberately omitted here. If removing old unused licenses, first preview license clean-up -unused -simulate and check the list; only then use license clean-up -unused when intended.

6.2 Verify LIFs, registration and service health

Use network interface show -is-home false to find LIFs away from their home ports. The source calls them LUNs in one sentence; these are logical interfaces. Return applicable LIFs using the documented network interface revert -vserver * -lif * procedure after reviewing the scope.

Register the replacement serial number through an AutoSupport message, or contact NetApp Support if AutoSupport is not enabled. Check cluster health using the linked guidance. End the maintenance window and restore automatic giveback if it was disabled:

system node autosupport invoke -node * -type all -message MAINT=END
storage failover modify -node local -auto-giveback true

6.3 Two-node MetroCluster switchback checks

For this branch only, verify enabled nodes using metrocluster node show. The source’s example before switchback is:

cluster_B::>  metrocluster node show

DR                           Configuration  DR
Group Cluster Node           State          Mirroring Mode
----- ------- -------------- -------------- --------- --------------------
1     cluster_A
              controller_A_1 configured     enabled   heal roots completed
      cluster_B
              controller_B_1 configured     enabled   waiting for switchback recovery
2 entries were displayed.

Confirm SVM resynchronization using metrocluster vserver show (the current English command name, rather than the source’s informal “SVM show”). Verify automatic LIF migrations with metrocluster check lif show. From the surviving cluster, perform metrocluster switchback when the required checks permit it. This is the same recovery action referenced earlier, not an instruction to repeat an already completed switchback.

Monitor metrocluster show. The waiting state is still in progress:

cluster_B::> metrocluster show
Cluster              Configuration State    Mode
--------------------	------------------- 	---------
 Local: cluster_B configured       	switchover
Remote: cluster_A configured       	waiting-for-switchback

Both clusters must return to normal for the illustrated completion state:

cluster_B::> metrocluster show
Cluster              Configuration State    Mode
--------------------	------------------- 	---------
 Local: cluster_B configured      		normal
Remote: cluster_A configured      		normal

For a long-running switchback, inspect metrocluster config-replication resync-status show. Reestablish any SnapMirror or SnapVault configurations as required. Follow the replacement kit’s RMA instructions for returning the failed part.