IBM Storwize V3700: Drive and Power Supply Replacement Case, with Management IP Setup

This field case covers two IBM Storwize V3700 systems. The upper unit reportedly had three failed drives; the other had one failed drive and one failed power supply. Management-network access was also requested for remote checks. English figures recreate the supplied screens and preserve their redactions. They illustrate the recorded case, not a repair performed or verified here. The source figures carry CSDN attribution; original author credit remains in the linked source article.

1. Configure the management-network address

Use the customer-assigned management IP address, subnet mask and gateway. In Settings > Network > Management IP Address, select the port actually connected to the management switch and enter the approved values. The example selects Ethernet port 2 (backup); it does not establish that port 2 is correct for every installation. Reconnect with the new address after a change.

English illustration of V3700 management address settings on Ethernet port 2 — Cluster identifier and address fields remain obscured; no usable addresses can be recovered from this figure.

Label both ends of each management cable. Record the storage unit, enclosure/rack position, rack U, management-switch identity and switch port so that the two systems can be distinguished during later maintenance.

2. Identify the failed drive and follow the applicable fix procedure

Log in to the storage management GUI and correlate the drive ID, enclosure and physical slot. Use Identify to illuminate the relevant indicator and label the confirmed slot temporarily. Verify the actual fault and array status before removing a drive; an obscured slot in a photograph is not sufficient identification.

The archived GUI path is Pools > Internal Storage > Configure Storage. The source marks an already identified failed member as Unused before replacement:

English illustration of failed Drive 6, 558.41 GB, Offline, with Mark As Unused highlighted — The drive-slot value is deliberately hidden because it cannot be confirmed from the source. Enclosure ID 1 remains visible.

This is a historical workflow, not an instruction to mark a healthy member Unused. Use the management GUI’s guided fault repair and the replacement procedure for the installed software and drive assembly. Replacement recognition and spare assignment depend on that version; do not force a state change merely to match this old menu.

In the case record, after insertion the replacement was found at the same physical slot with no MDisk name and with Use = Unused / Status = Online:

English illustration of a replacement drive shown as Unused and Online with an empty MDisk name — Blurred drive IDs, capacity and slots remain unspecified.

The source then assigns the eligible replacement as Spare. Confirm whether the current fix procedure performs that assignment automatically or requires the manual operation, and monitor the actual rebuild and array state before continuing.

3. Distinguish a failed spare from a failed array member

The source separately records an offline spare. Its row identifies Drive 11 as Spare / Offline; the capacity prefix and identifying columns are obscured:

English illustration of offline spare Drive 11 with identifying fields obscured — Only the suffix 41 GB is readable in the capacity field; it is not a complete drive-capacity value.

In that state the source shows all three Mark As choices disabled. Disabled controls are not permission to bypass fault checks or remove an arbitrary drive:

English illustration with Unused, Candidate and Spare all disabled

After positively identifying the failed spare and following the applicable removal/replacement procedure, the case assigns the recognized replacement to Spare:

English illustration with Spare enabled and highlighted — The two menu illustrations show different source states; Spare must not be interpreted as enabled in the preceding figure.

4. Read the capacity evidence without deriving an unverified RAID layout

The source describes twenty nominal 600 GB SAS drives and RAID 5, with two hot spares. Its capacity formulas contain arithmetic errors and assume that all physical drives form one array. The screenshots show MDisk names but do not establish the complete member/parity layout. The IBM V7.8.x limits distinguish conventional and distributed RAID; conventional RAID 5 allows 3–16 members. That version-specific limit does not identify the software on these systems, but it demonstrates why twenty physical drives cannot simply be treated as one conventional RAID 5 MDisk. IBM V3700 V7.8.x configuration limits.

For decimal units, 1 TB = 1000 GB. The source expressions evaluate as follows; these are arithmetic corrections only, not verified usable capacities:

Expression used in source	Correct decimal result	Limitation
600 × (20 − 1)	11400 GB = 11.4 TB	Assumes one parity drive across all twenty drives
600 × (20 − 1 − 2)	10200 GB = 10.2 TB	Assumes two dedicated spares and one shared parity deduction
600 × 2	1200 GB = 1.2 TB	Nominal raw capacity of two drives, not the GUI spare reading
600 × (20 − 1 − 2 − 2)	9000 GB = 9.0 TB	Subtracting failed members does not calculate RAID availability or recovery

Do not relabel binary-sized GUI readings as decimal arithmetic results, or equate MDisk capacity with free application capacity. Use the actual drive sizes, array membership, RAID type, pool/volume allocation, rebuild status and display units. The recorded capacity panels are retained below without adjusting their totals:

English capacity panel: MDisk 10.36 TB, spares 1.09 TB, total 11.45 TB — The source bar reads 90%. This is a recorded capacity display, not a rebuild-completion percentage.

The failed-spare example shows only one spare’s displayed capacity:

English capacity panel: MDisk 10.36 TB, spare 558.41 GB, total 11.45 TB — The original panel still says total 11.45 TB; the apparent mismatch is preserved, not silently changed to 10.91 TB.

For the upper unit, the source reports two failed member drives and one failed spare. Its initial display is:

English capacity panel: MDisk 9.27 TB, spare 558.41 GB, total 10.91 TB — These aggregate readings do not establish whether the two reported failed members belonged to the same RAID 5 array, or whether all customer data remained accessible.

After replacing the two reported members, the source shows:

English capacity panel after the reported member replacements: 10.36 TB, 558.41 GB, 10.91 TB

After replacing the reported spare, the source shows:

English capacity panel after the reported spare replacement: 10.36 TB, 1.09 TB, 11.45 TB

Do not infer that ordinary single-parity RAID 5 can tolerate two concurrent member failures in the same array. The source’s suggestion to replace one or two drives at a time is not a general safe procedure. Follow the guided repair sequence for each confirmed failed FRU, check the actual rebuild/redundancy and host-data status, and wait for the required recovery before another replacement. The capacity crops alone do not prove a complete successful rebuild.

5. Replace the identified failed power supply

The case has dual power supplies. Correlate the fault indication, enclosure and exact PSU before removal, and confirm the remaining power path can support the enclosure. Follow Troubleshooting > Replacing parts > Replacing a Power Supply Unit in the V3700 documentation for the installed version; the source does not document the full cable, latch or electrical procedure. IBM’s V3700 Redbook directs readers to that version-specific procedure.

Use the supported replacement, align and seat it fully, and engage its latch. The source notes a tight fit; that is not an instruction to force a misaligned or incompatible unit. Verify the expected indicators and GUI state after replacement:

English PSU details showing unit 1 left Online, power and fan Normal — The source screen reports AC power Normal, DC power Normal, Fan Normal and Safe to remove Yes. FRU part number and part identifier remain obscured. These are recorded screen values, not a fresh safety assessment.

6. Record the outcome and protect the data

Before maintenance, check current faults, capacity usage and available backups. The source recommends taking a data backup where possible and keeping utilization below 80%; that percentage is a case recommendation, not a recovery guarantee or a substitute for checking RAID health. After each replacement, review fault clearance, member/spare status, rebuild completion and host access, and update the service record.

Preserve the storage configuration separately when required. A configuration backup contains configuration information rather than customer volume data, so it does not replace a backup of the applications and stored data.

References

The official English materials provide applicable terminology and version-specific checks. They are not exact English copies of the field-case photographs, and the original case does not identify its installed software version.