HPE 3PAR Administration: Common CLI Commands by Category

2026年9月2日 LOG admin

HPE 3PAR arrays are powerful but notoriously verbose to administer, and most daily tasks - checking alert state, finding a failed disk, mapping a volume to a host - start with the right show command. This article groups the common 3PAR CLI commands by administration task so storage admins can find the exact command without paging through the full command-line interface reference guide.

Where the HPE 3PAR CLI cheat sheet is an inventory of commands organised by object type, this article is the operational companion: it walks through the recurring jobs a 3PAR administrator actually performs — provisioning a volume from CPG to host, taking and restoring snapshots, growing volumes safely, verifying that a host really has its paths, triaging alerts, and replacing a failed disk — and shows which commands form each sequence, in the order you should run them.

Ground Rules Before You Type Anything

Three habits prevent most 3PAR administration incidents. First, read before you write: never run a create*, grow*, set* or remove* command without first running the corresponding show* to confirm the object name, the CPG it lives on and the space available. Second, quote and verify names: volume and CPG names are case-sensitive and must be quoted when they contain special characters, and a typo in a removevv is unrecoverable without a restore. Third, know your provisioning type: thin-provisioned (-tpvv), fully provisioned, or deduplicated (-tdvv) volumes behave differently when they fill, and that difference decides which space command you need later.

System Health and Status Commands

cli% showalert -n                # new alerts
cli% showalert -v                # verbose alert details
cli% showsys -d                  # system model, serial number, details
cli% showversion                 # software versions
cli% showdate                    # date/time on all nodes
cli% shownodeenv                 # node environmental status (voltages, temps)
cli% showeventlog -min 20        # events in the last 20 minutes

showsys -d is usually the first command support asks for, and showeventlog quickly surfaces what changed right before a problem.

Physical Disks, Cages and Ports

cli% showpd                    # all physical disks
cli% showpd -failed -degraded  # failed and degraded disks
cli% showpd -c <diskid>        # chunklet details for one disk
cli% showpdch -fail            # every failed chunklet in the system
cli% showcage -d <cage>        # cage details
cli% showport                   # FC and iSCSI ports
cli% showportlesb              # Link Error Status Block (fibre errors)

showpd -failed -degraded is the fastest way to answer "do I have a bad disk", and showportlesb exposes link error statistics when hosts report flaky storage connectivity.

Virtual Volumes, CPGs and Mapping

cli% showcpg                   # Common Provisioning Groups
cli% showvv                    # virtual volumes
cli% showvv -v <vvname>        # details for one volume
cli% showvlun                  # all LUN exports
cli% showvlun -v <vvname> -pathsum   # paths for a volume
cli% showvlun -host <host> -pathsum  # paths for a host
cli% showhost -desc <host>    # host details incl. WWNs
cli% showvvmap                 # VV to LD mapping
cli% showld                    # logical disks

When a host "lost its disk", the classic diagnostic sequence is showvlun -host <host> -pathsum to confirm the expected number of paths, then showportlesb and showpd to isolate whether the problem is in the fabric or the array.

Provisioning and Maintenance Commands

cli% createvv -spt -usr_cp -sdg CPG1 -p VV1 100g
cli% growvv -p VV1 50g
cli% removevv VV1
cli% createvlun -host <host> -auto VV1
cli% checkhealth               # overall system health checks
cli% checkpd -s <diskid>       # disk surface scan

Volume and CPG names must be quoted or escaped when they contain special characters, and destructive commands (removevv, removevlun) prompt for confirmation before executing.

Workflow: Provisioning a Volume from CPG to Host

This is the end-to-end provisioning sequence, in order. Resist the temptation to skip step one — checking the CPG first tells you the device type, RAID level, and how much free space is really available, which is exactly the information you need to pick a sensible volume size.

# 1. Confirm the target CPG and its free space
cli% showcpg -sdg CPG1
cli% showcpg -d CPG1

# 2. Confirm the host object exists and has the right WWNs/IQNs
cli% showhost -d host1

# 3. Create the volume (thin-provisioned, user CPG = CPG1)
cli% createvv -spt -usr_cp -tpvv CPG1 VV1 500g

# 4. Verify size, provisioning type and policies
cli% showvv -v VV1

# 5. Export it to the host, letting the array pick a free LUN ID
cli% createvlun VV1 auto host1

# 6. Verify the export and the path count
cli% showvlun -v VV1
cli% showvlun -host host1 -pathsum

Note the argument order in createvv: options first, then the CPG, then the volume name, then the size. Administrators coming from other arrays frequently reverse the last two. After step 5 the host needs a rescan before the new LUN appears — on Linux rescan-scsi-bus.sh or a multipath reload, on ESXi a storage adapter rescan, on Windows a disk rescan in Disk Management.

The provisioning-type flags you will use most often:

-tpvv      thin provisioned (allocate on first write)
-spt       snapshot-capable parent volume
-tdvv      deduplicated thin volume
-fpvv      fully provisioned
-sa        skip acknowledgement prompts
-nowait    return immediately with a task ID

Workflow: Mapping a Volume and Verifying Paths

Mapping problems are the most common 3PAR support call, and almost all of them are path problems rather than volume problems. Work outward from the volume, not inward from the host.

# What is exported, and to whom?
cli% showvlun -v VV1

# For a specific host: how many paths, and in what state?
cli% showvlun -host host1 -pathsum

# Compare against the expected path count for this host's HBA pair
cli% showhost -d host1

# Are the array-side ports healthy?
cli% showport
cli% showportlesb -state
cli% showportlesb -summary

# Is the host's LUN visible at all?
cli% showvlun -host host1 -lun <lunid>

A healthy dual-fabric FC host shows four paths to a single array node pair (two HBAs × two array ports across two fabrics). Anything less means a fabric zone, an array port, or an HBA has gone missing. Add or remove an export deliberately: createvlun to add, removevlun to remove, and always follow with showvlun -host <host> -pathsum to confirm the change took effect. When you need a specific LUN ID rather than an automatic one, pass the number instead of auto, and avoid IDs a host already uses.

Workflow: Snapshots (Virtual Copies) and Restores

3PAR snapshots are virtual copies — at the moment of creation they consume almost no space, then diverge as either the source or the copy is written. That behaviour makes them cheap and fast, and it also means a snapshot you forget about can grow silently.

# 1. Create a writable snapshot of a volume
cli% createvvcopy -p VV1 SNAP_VV1

# 2. Or create a read-only virtual copy of a VV set
cli% createvvsetcopy -ro -p VV1 VVSET1

# 3. Verify the copy exists and its parent
cli% showvv -v SNAP_VV1
cli% showvv -s SNAP_VV1        # space consumed by the snapshot

# 4. Export the snapshot for recovery / testing
cli% createvlun SNAP_VV1 auto host_lab

# 5. When finished, remove the export and the snapshot
cli% removevlun SNAP_VV1 auto host_lab
cli% removevv SNAP_VV1

For scheduled protection, configure a snapshot policy rather than creating copies by hand — showsched and showvv -sched show what is already scheduled, and the policy is applied with the volume's snapshot settings. Whenever you delete a snapshot, check showvv -s first to see how much space it is holding; reclaiming a large snapshot can free a surprising amount of the CPG. Remember the retention rule: a snapshot protects against logical damage such as an accidental file deletion or a bad upgrade, not against the loss of the array itself. That is what Remote Copy is for.

Workflow: Growing and Reclaiming Space

A volume that is filling up is handled differently depending on its provisioning type. Thin volumes grow on demand and warn when the CPG itself runs low; fully provisioned volumes need an explicit grow.

# Which volumes are close to full?
cli% showvv -s

# How much free space is in each CPG?
cli% showcpg -sdg

# Grow a thin volume (metadata only - very fast)
cli% growvv -tpvv VV1 200g

# Grow a fully provisioned volume
cli% growvv -p VV1 200g

# Check which physical disks will back the new space
cli% showvv -s VV1
cli% showpd -c

Growing a thin volume is a metadata operation and returns almost instantly; growing a fully provisioned volume allocates real chunklets and may take time and generate a task. In both cases confirm afterwards with showvv -s that the reported size and reserved space match what you intended. If a CPG is genuinely out of space, the fix is to add capacity (disks, or a new CPG on a new tier) and, for thin volumes, ensure the growth can be satisfied — an over-committed thin CPG running out of space is one of the few ways a 3PAR environment takes an outage from the storage side.

Workflow: Responding to a Failed Disk

3PAR RAID is designed to survive disk failures, but a failure is only safe once the spare and rebuild are healthy. Confirm three things before you relax.

# 1. Is a disk failed or degraded?
cli% showpd -failed -degraded

# 2. Are there failed chunklets, and where?
cli% showpdch -fail
cli% showspare

# 3. Is the spare being used / is a rebuild running?
cli% showspare -d
cli% showtask -active -d

A degraded (rather than failed) disk is often still serving data and should be replaced deliberately, in a maintenance window, not yanked. The replacement procedure is a servicemag workflow — move the magazine to a maintenance state, replace the disk, then servicemag resume — and it is covered in detail in our 3PAR disk replacement and servicemag workflow guide. The thing administrators most often skip is running showtask -active -d afterwards: a rebuild that is still running is a period of elevated risk, and you want to know when it completes.

Workflow: Alert Triage and Escalation

Alerts are only useful if they are read. The routine below turns an alert into either a fix or a support case.

# 1. What is new?
cli% showalert -n

# 2. Full detail for the specific alert
cli% showalert -d

# 3. What happened just before it fired?
cli% showeventlog -min 60

# 4. Is the system otherwise healthy?
cli% checkhealth -svc

# 5. Any long-running tasks that might explain it?
cli% showtask -active -d

# 6. Acknowledge once resolved
cli% dismissalert <alert_id>

The checkhealth command automates a large set of component checks, and its output is what HPE support expects when a case is opened. If it reports errors, decode them with the HPE 3PAR error codes and checkhealth troubleshooting guide before escalating — many codes are resolved by a documented corrective action rather than a part swap. checkhealth -svc -detail produces the fuller report; pipe it to a file and attach it to the case.

Remote Copy Administration Basics

When the array participates in replication, the daily check is short but important: is each group syncing, and is the transport link healthy?

cli% showrcopy -d                 # groups, targets, states
cli% showrctransport -d           # link throughput and latency
cli% showpeer -d                  # partner array state
cli% showrcopy -d <group>         # one replication group in detail

A group in Syncing or Started state with a growing lag is the signal to look at the transport before users notice. For the failover design that sits on top of Remote Copy, see our HPE 3PAR Primera Peer Persistence guide. Multipath behaviour on the host side — which is what makes a path failure transparent — is covered in the Linux multipath configuration guide.

Administration Habits That Prevent Outages

Never grow a volume from memory. showvv -v first, then growvv, then showvv -s. Two seconds of reading prevents most sizing mistakes.
Check showtask -active -d before every maintenance action. A tunesys, servicemag or volume move in progress changes what is safe to do next.
Record the serial number and software version in your CMDB. showsys -d and showversion are the first questions in any support interaction, and having them to hand saves a round trip.
Watch CPG free space, not just volume free space. showcpg -sdg is the early-warning system for thin environments.
Treat snapshots as temporary. Review them monthly with showvv -s; a forgotten snapshot on a busy volume can consume more space than the volume itself.
Use CSV output for inventory. setclienv csvtable 1 turns command output into something your documentation pipeline can consume instead of something you copy by hand.