Checking storage array configuration from the CLI

From the serial console session to the replacement node, check the SDs are present and OK by running: pn all scsi-racks
1. pn all scsi-racks
  If the output does not show the replacement node and all the ports from the replacement node, recheck the storage reconfiguration on all VSP One File HostGroups.
2. pn all sd-list
```
$ sd-list
Device	Status	     Alw		GiByte	    Mirror	     In span          Span Cap
0		OK		Yes		5120		Pri		FSS_Pool_1	163840
1		OK		Yes		5120		Pri		FSS_Pool_1	163840
4		OK		Yes		5120		Pri		FSS_AMS200	163840
5		OK		Yes		5120		Pri		FSS_AMS200	163840
6		OK		Yes		5120		Pri		FSS_AMS200	163840
7		OK		Yes		5120		Pri		FSS_AMS200	163840
```
If the SDs show not present, recheck the zoning and the HostGroup wwn settings. If any of the SDs show unusable, Type scsi-refresh to rescan the scsi bus. If the server does not recognize the system drives, enter fc-link-resetto reset the fiber paths.
Check the FC Link Speed
1. Run fc-link-speedto verify and, if necessary, configure the FC port speed as required.
2. Run fc-link-speed-iport number -s speed for each port.
The maximum Fibre Channel (FC) link speed on the replacement server is 32 Gbps.
Check the SD Pathing
1. Run sdpathcommand to display the path to the devices (system drives) and the port and storage port that are used.
Check the Spans are accessible.
1. Run span-list to verify the storage pools (spans) are accessible. In this instance, cluster is synonymous with the stand-alone server.
2. Run span-list-cluster-uuids span_label to display the cluster serial number (UUID) to which the storage pool belongs.
  The UUID is written into the storage pool configuration on disk (COD). The COD is a data structure stored in every SD, which provides information how the different SDs are combined into different stripesets and storage pools.
3. Enter the span-assign-to-cluster span_label to assign all the spans to the new server.

Final Storage Procedures

From the server CLI session, record the printable output from the putty session to a file.

Type the following commands:

pn all sd-list
pn all scsi-racks
pn all sdpath
pn all fc-host-port-load
pn all fc-target-port-load
trouble

Collect Diagnostics from the File Administrator
Upload the putty output and diagnostics to TUF under the case opened for the replacement.
Check the event log for any obvious serious events.

Migrating EVS

From a browser, connect to the File management software, and log in as admin.
Navigate to File Administrator > Provisioning > Enterprise Virtual Server.
1. Migrate at least one of the EVSs onto the replacement node and verify customer connectivity to the file systems on that EVS.
2. If the test is successful, migrate all the remaining EVSs that were initially on the defective Node to the replacement node.

Final steps

Navigate to File Administrator > Configuration > System > System Overview to verify the cluster configuration status. Verify the cluster is shown as Online and has the correct number of nodes
Confirm all final settings, IP addresses, customer contact information, service restarts, client access, and that customer expectations are all in place. Features such as replication and data migration must all be confirmed as working, and all file systems and storage pools must be online
Send an email to TBKeys@hitachivantara.com with the following information, requesting the Customer's license keys be transferred from the original Node replaced to the replacement node.
- MacID of the original Node
- MacID of the replacement node
Open an SDM (Service Data Management) case to change the asset serial number from the Replaced Node to the Replacement Node.
- Serial Number of the replaced Node
- Serial Number of the replacement node

Verify that the Customer can access their data