HPE 3PAR Disk Replacement: showpd and servicemag Workflow

Replacing a failed disk in an HPE 3PAR StoreServ array looks simple - pull the drive, push a new one - but doing it without the right CLI sequence can leave the array degraded or, worse, block the replacement because chunklets on the failed disk are still owned by a CPG. The safe workflow is: identify the failed physical disk (PD), let the system relocate its chunklets, bring the magazine offline with servicemag, swap the drive, resume the magazine, and verify with checkhealth. This guide walks through each step with the exact commands.

3PAR Storage Vocabulary You Need First

Almost every failure during a disk swap comes from confusing one of these layers with another, so it is worth naming them explicitly before you touch a drive:

• Physical disk (PD) - the actual drive, addressed by Id and by its CagePos in the form cage:magazine:bay (for example 1:1:0).
• Chunklet - the 1 GB unit of raw capacity that 3PAR allocates. Every chunklet lives on exactly one PD until it is moved.
• Logical disk (LD) - a RAID group assembled from chunklets that may be spread across several PDs. The LD RAID type determines how much protection you keep when one of those PDs dies.
• Common Provisioning Group (CPG) - the pool of LDs from which virtual volumes are thinly provisioned. A CPG owns the chunklets that a failed PD is still holding, which is exactly why a naive removal fails.
• Virtual volume (VV) - the LUN or file presented to a host. It is backed by LDs, and indirectly by the chunklets you are trying to evacuate.
• Magazine - the removable drive carrier inside a cage, typically holding four small-form-factor drives. It is addressed as cage:magazine, which is why servicemag takes two numbers.
• Cage - a drive enclosure. Cage 0 is usually the internal enclosure of the controller node; external JBODs start at cage 1 and upwards.

If this hierarchy is unfamiliar, the HPE 3PAR CLI command cheat sheet is the fastest way to build a mental map of showpd, showcpg, showld and showvv before you run them in anger.

Before You Start: Prerequisites and Pre-flight Checks

A disk replacement is a low-risk operation only when the array is healthy enough to absorb it. Confirm the following before you schedule a maintenance window:

• You have physical access and the correct spare. Match the drive type, capacity and interface exactly. Mixing a drive class into a magazine the array does not expect is not supported; never guess.
• Array health is otherwise clean. A second failure during the swap is the only thing that turns a routine replacement into a data-loss event, so run a full health check first.
• You know the redundancy state. If the failed PD contained chunklets in a RAID 5 set that is already degraded, evacuating further chunklets will not be possible until the set is rebuilt. Check logical disk state before you start.
• You have a support case open if the drive is under warranty - HPE can refuse to ship a replacement if the array serial and the PD serial are not on record.

cli% showversion -b
cli% checkhealth -svc -detail
cli% showpd -s -failed -degraded
cli% showld -state degraded
cli% showcpg

The -svc -detail form of checkhealth is the one service engineers actually read: it groups every alert by component and classifies severity, so a single scan tells you whether the array is a good candidate for a live disk swap.

Step 1: Identify the Failed Disk

Find the failed or degraded PDs and record their cage/magazine position, model and serial number:

cli% showpd -s -failed -degraded
Id  CagePos  Type  -State-  Detailed_State
13  1:1:0    NL    failed   vacated,invalid_media,media_failed
22  1:13:0   NL    failed   vacated,invalid_media,smart_threshold_exceeded

cli% showpd -i -failed -degraded
Id  CagePos  State  --Node_WWN--  -MFR-  --Model---  -Serial-  Protocol  MediaType

Note the Id and CagePos (cage:magazine:bay) values - you will need them for the replacement steps. The Detailed_State column is worth reading carefully before you escalate: media_failed means the media itself is dead, while smart_threshold_exceeded means the drive is still readable but predicted to fail. Both warrant replacement, but only the first is an emergency.

Record the serial number and the magazine position in your change ticket. On a dense array with dozens of visually identical carriers, the serial is the only reliable way to prove you pulled the drive you intended to.

Step 2: Check Chunklet Ownership First

Before you can remove a disk, it must be free of chunklets. If chunklets are still mapped to a CPG or VV metadata, dismisspd will fail. Check the current placement:

cli% showpd -v 13
cli% showcpg
cli% showvv -pd 13
cli% showpd -showcols id,model,status,owned_by,ownertype,chunklets,failed

If the CPG has free capacity elsewhere, the 3PAR background rebalancer relocates chunklets automatically - monitor until the PD shows zero chunklets referenced. If the disk is truly dead and chunklets cannot be evacuated, contact HPE support to clear the stale metadata safely.

How Chunklet Evacuation Actually Works

Understanding the evacuation mechanism removes most of the guesswork from a swap. When a PD is marked failed, 3PAR does not read data off the dead drive; instead it relies on the RAID parity that already exists across the surviving members of each LD. The array reconstructs the missing chunklets from parity and writes the rebuilt copies into the spare chunklet pool, then into any CPG that has free capacity. Three consequences follow:

• Evacuation is read-from-parity, not read-from-disk. A drive that is fully dead still evacuates - as long as the rest of its LD set is online.
• You need spare capacity. If every CPG is full and there is no spare chunklet pool, the rebuild has nowhere to land and the LD stays degraded. Freeing space before a planned replacement is cheap insurance.
• It takes time and I/O. Rebuild consumes backend bandwidth. On a busy array, schedule the swap outside the peak window so parity reconstruction does not compete with production reads.

The same mechanism protects you in the reverse direction: when the new drive is claimed, its chunklets enter the spare pool and the array can rebalance onto them later. The rebalancer is opportunistic and low-priority by design, which is why a freshly rebuilt array can look "uneven" for hours and still be perfectly healthy.

Step 3: Bring the Magazine Offline

With the failed PD identified and freed, take the magazine offline so the drive can be pulled safely:

cli% servicemag start 1 1
cli% servicemag status -d 1 1

Wait until servicemag status shows the magazine is offline/succeeded before touching the hardware. To blink the LEDs on the magazine for easy identification in the data center:

cli% locatecage -t 255 <cage_name>

In a shared rack this is not a cosmetic step. locatecage turns on the enclosure locator LED for a bounded number of seconds and lets you confirm visually that the magazine you are about to open is the one the software believes is offline. Pulling the wrong carrier is the most damaging single mistake available in this workflow.

servicemag, admithw or dismisspd?

The three commands overlap enough that operators reach for the wrong one under pressure. The distinction is simple:

• servicemag - take an existing magazine offline, replace a drive inside it, and bring it back. Use it for a like-for-like swap in a magazine the array already knows.
• admithw - claim hardware the array has not yet inventoried: a brand-new cage, a newly added magazine, or a drive added for capacity rather than replacement.
• dismisspd - remove a PD from the array's inventory entirely, after its chunklets are evacuated and you do not intend to replace it in place.

Using admithw when a servicemag was expected leaves stale locator records; using servicemag on hardware the array has never seen produces an inventory mismatch. If you are unsure which applies, showpd will tell you whether the bay is empty-and-known or entirely absent from the inventory.

Step 4: Replace the Drive and Resume

Physically replace the disk in the magazine, then tell the array to resume and claim the new drive:

cli% servicemag resume 1 1

The system will start checking the new disk. For brand-new cages or when adding hardware, use admithw instead - servicemag is for replacements.

Resume is the point at which the array writes the new drive's identity into its configuration. Until the command completes, the bay is still considered offline; if you interrupt it or remove the magazine mid-resume you will need to repeat the start step before the array will accept the drive again.

Step 5: Verify Health

Once the new PD is online, confirm it was claimed and run the health checks:

cli% showpd
cli% showpd -s -failed -degraded
cli% checkhealth pd
cli% checkhealth -svc -detail

checkhealth performs comprehensive checks of every component (alert, cage, node, pd, ld, port, vlun, vv and more); the -svc -detail form gives the full service summary with each alert classified.

A clean replacement shows the new PD as normal in showpd, an empty result from showpd -s -failed -degraded, and no new alerts in the service summary. The LD that was degraded should return to normal once parity reconstruction finishes, which may lag the physical swap by minutes to hours.

Replacing a Drive vs Adding Capacity

The workflow above assumes one failed PD replaced by an identical one. Adding capacity is a different exercise with different risks:

• Adding a drive to an existing magazine uses admithw followed by adding its chunklets to a CPG; the array inventory grows and the rebalancer spreads existing data across the new space.
• Adding a whole new cage needs physical cabling to both controller nodes, a rescan, and then admithw. Missing the second node's path is a common cause of "cage seen but no disks" symptoms.
• Growing a CPG is a separate, deliberate decision - never let a disk swap silently change the capacity model your change records describe.

If parity and RAID concepts are the part you want to firm up first, the explanation of RAID levels and the parity write hole is a useful companion read, because it explains exactly what parity protects during a rebuild and what it does not.

If the Replacement Fails

• servicemag status shows the magazine did not come offline: re-check that no I/O is pinned to the magazine and that no other drive in it is in a transitional state.
• New disk shows as failed or not normal: give the array time to run its checks, then review showpd detailed state; a SMART threshold failure on the replacement means the drive itself is bad.
• dismisspd fails: the PD still owns chunklets - revisit Step 2 and evacuate before removing.

Field Replacement Checklist

1. Open a change ticket and record the failing PD's Id, CagePos and serial from showpd -i.
2. Run checkhealth -svc -detail and confirm no unrelated critical alerts.
3. Free CPG capacity if the array has no spare chunklet pool.
4. Wait for chunklet evacuation to complete and re-verify with showpd -v.
5. servicemag start <cage> <mag>, then locatecage to confirm the right magazine visually.
6. Pull the failed drive, insert the matching spare, confirm it seats fully.
7. servicemag resume, then showpd until the PD is normal.
8. Run checkhealth pd and checkhealth -svc -detail, confirm degraded LDs rebuild, and close the ticket with the serial numbers of the drive removed and the drive installed.

If a controller rather than a disk is the failed component, the procedure is entirely different; the controller replacement walkthrough is covered in the guide to HPE 3PAR controller failure and offline replacement. For day-to-day administration beyond disk service, the broader HPE 3PAR CLI administration commands reference covers the rest of the toolkit.

Related reading: HPE 3PAR CLI command cheat sheet and HPE 3PAR error codes and checkhealth troubleshooting.

Original article: HPE Community: Adding/replacing disks on 3PAR StoreServ