Upgrades, Serviceability, and Troubleshooting
The last domain covers keeping the array current and repairing it: upgrade mechanics, service tooling, log collection, and escalation discipline.
Upgrades
- PowerStoreOS upgrades are non-disruptive: nodes upgrade one at a time with I/O failed to the peer, so hosts may see a path flap but not an outage.
- Start upgrades from PowerStore Manager under Support > Upgrade by uploading the image, or schedule them. A health check runs first and can block the upgrade.
- Clear blockers before retrying: a failed drive, a degraded component, or a replication session in a bad state will fail the pre-check.
- Check the recommended upgrade path; some releases require an intermediate hop, and the interoperability matrix must confirm host multipathing and firmware support.
- Upgrade Extensions packages deliver non-OS fixes and should be kept current alongside the OS.
Serviceability
- Service tasks run as svc_-prefixed scripts over SSH to a node using the service account; svc_help lists what is available on that node. They are used under Dell direction, not as casual troubleshooting.
- Collect support materials from PowerStore Manager before any disruptive action; logs from before the event are what support needs.
- SupportAssist supplies call-home, remote access, and CloudIQ onboarding. Without it a failed component waits for a human to notice.
Troubleshooting approach
- Identify the layer: host, fabric or network, array front-end, array back-end, or capacity.
- Read Alerts first, then Events for the timeline, then Jobs for what changed.
- Check both nodes; a node-down condition changes the entire diagnostic path.
- Confirm host multipath output before touching array-side mapping.
- Escalate with support materials and a precise timeline.
Worked example
An upgrade stops at the pre-check with a health warning about a drive. Reasoning: do not override. Replace the drive, wait for the rebuild job to finish, confirm the health score is clean with no active alerts, then re-run the upgrade. Forcing an upgrade through with a degraded component risks a second failure inside the node-reboot window, when there is no redundancy left to absorb it.
Traps
- Scheduling a full outage for an upgrade that is non-disruptive.
- Re-running service scripts or rebooting a node to clear an alert without a support case.
- Skipping the upgrade path check or the host interoperability matrix.
- Collecting support materials only after the failure, losing the pre-failure state.