IBM Storwize V7000: Legacy Maintenance Reference

This note describes an early Storwize V7000 environment and 6.x-era interfaces. It is not a common service procedure for every later IBM V/FlashSystem model. Literal source default passwords are omitted.

1. Hardware and management addresses

The source describes a 24-drive control enclosure with PSUs at the sides and two node canisters. It lists historical service addresses 192.168.70.121 and 192.168.70.122 for the upper/lower canisters; verify the actual port, address and physical orientation in the matching guide. The cluster/system management IP is configured when the clustered system is created and is distinct from a node’s service address.

To recover address/status information, the source inserts a clean USB key into a node canister and waits until the service/fault indicator stops flashing before removal. Read satask_result.html on a workstation. IBM’s matching 6.3 guide confirms that a key without satask.txt can produce status/configuration output, while a key containing that file can execute service commands. Ensure the key contains no unintended command file; this is not an initialization or reset step.

2. Initial setup

The source uses the supplied initialization USB tool (InitTool.exe) to prepare the appropriate satask command file for mkcluster, or uses an SSH-based setup. This is for the intended uninitialized system; do not repeat initialization on an existing production cluster. Use the version/model-specific installation procedure.

3. Management interfaces

The cluster GUI in a browser.
The node Service Assistant at https://<SERVICE_IP>/service/. The source lists node-specific logs, shutdown/restart/service mode, cluster recovery, node software updates, service-IP changes and related service controls. Each has its own prerequisites.
The supported SSH CLI.

4. Logical objects and configuration

The source abbreviates its storage layers. More precisely, internal RAID arrays or external storage can provide MDisks; storage pools group managed capacity; vdisks/volumes present logical storage to mapped hosts. A pool is not itself the same object as a RAID array. Its setup flow is: prepare managed storage, create the pool and volume, define the host, then map the volume.

5. Support logs

In the source GUI, open Troubleshooting > Support > Download Support Package. Four options are listed; it generally chooses Standard logs, leaving other collections to support direction. Its approximate five-minute collection time is an observation, not a timeout guarantee. Service Assistant can collect data for the selected node; a node-only collection does not necessarily replace all cluster diagnostics.

6. Power sequence

For the source hardware, expansion enclosures start before the control enclosure, and the control enclosure shuts down before the expansions. First perform the supported cluster/system shutdown in the GUI; do not simply switch off both control-enclosure PSUs while the system is running.

The source path is Monitoring > System Details, select the V7000 system icon, then Actions > Shut Down Cluster and confirm. Verify completion with the actual version’s procedure before removing power.

7. Drive service

The source lists drive, PSU, battery, controller and SFP failures. Prefer the GUI’s event-directed fix procedure for the exact failed component. Its manual drive-state examples are:

svctask chdrive -use failed <DRIVE_ID>
svctask chdrive -use unused <DRIVE_ID>
# After the appropriate replacement / validation:
svctask chdrive -use candidate <DRIVE_ID>
svctask chdrive -use spare <DRIVE_ID>

These change drive state and are not a generic four-command sequence to run on a healthy/member disk. Confirm the drive identity, array redundancy/rebuild state and applicable IBM procedure before removal or state changes. Ghost-drive behavior can be firmware/problem specific; do not assume every direct replacement creates a ghost entry or that forcing states resolves it.

8. PSU and battery service

The source checks Safe to remove = Yes under the selected device’s properties before PSU/battery replacement. A No state requires investigation of the partner PSU/battery and service procedure. Its matching early V7000 guide limits an empty PSU slot on a running enclosure to five minutes for cooling and describes transferring the existing battery to a replacement PSU supplied without one. Prepare the matching replacement and follow the guided fix.

The source warns against a spare battery stored for more than two months and says a long-stored battery may no longer charge. That two-month threshold was not independently confirmed as a universal rule; check the exact battery’s storage/charge requirements and service diagnostics. It also reports loud fans during PSU/battery firmware synchronization. Wait for and verify the reported update/health state; fan noise alone does not prove update success or that another battery is needed.

9. Historical software-upgrade workflow

The source first requires a healthy system and the correct controller/drive packages plus the current upgrade-test utility. Its 6.3-era GUI path is Settings > General > Upgrade Software > Launch Upgrade Wizard. Upload the matching upgrade-test utility, select the actual supported target version, resolve all errors/warnings, then upload the correct system package and monitor progress.

The source’s target example is 6.2.0.1 despite describing a 6.3-era interface. This is not a validated upgrade path or recommendation to downgrade. It reports node2 then node1 processing, about 30 minutes per node and 90–120 minutes overall; these are historical observations. Use IBM’s supported upgrade path, compatibility checks and completion criteria for the exact system.

IBM’s official English V7000 Version 6.3.0 troubleshooting/recovery/maintenance guide provides the matching-generation reference. No storage, state, power or firmware operations were executed to prepare this translation.