How to Install and Configure PowerPath on Solaris

— ny_wk

Installing and configuring PowerPath on Solaris gives a SPARC or x86 host fault-tolerant, load-balanced access to EMC/Dell SAN storage by presenting every physical I/O path to a LUN as a single emcpower pseudo device. This guide walks through the full workflow: confirming the license, configuring paths with powermt, surfacing the pseudo devices in format and Veritas, and verifying that multipathing actually works.

Before you start: EMC PowerPath and the CLARiiON/VNX arrays referenced here, along with Oracle Solaris 10, are legacy and end-of-life technology. The procedure below is accurate for environments still running them, but on a greenfield build you would use Solaris native multipathing (MPxIO / stmsboot) or, on a modern array, the vendor's current multipathing stack. The modern-equivalent note at the end explains the migration path.

What PowerPath on Solaris actually does

A SAN LUN is usually reachable through more than one Fibre Channel path: two or more HBAs, two storage processors (SP A and SP B), and multiple front-end ports. Without multipathing software, Solaris sees the same LUN as several separate disks (one per path), which is dangerous and offers no failover.

PowerPath solves this by claiming all paths to a LUN and exposing one pseudo device named emcpowerN (for example emcpower0a). I/O is then spread across the live paths according to a load-balancing policy, and if a path, port, or SP fails, I/O transparently continues on the survivors. That is the fault tolerance the application requires.

Pre-deployment requirements

• Root access on the Solaris host (log in as a normal/domain account, then escalate).
• At least one SAN LUN already zoned and masked to the host's HBAs that should be protected by PowerPath.
• A valid PowerPath license key registered on the host.
• The PowerPath package matching your Solaris release and architecture (SPARC vs x86), plus a maintenance window if a reboot is needed.

Step 1 — Verify the PowerPath installation and license

First escalate to root. Log in with your normal account, then switch user:

1. Become root:
   sudo su -
2. Confirm the license is registered and the product is licensed for all capabilities:
   powermt check_registration

A healthy response shows a registered key and full capabilities, for example:

• Key ABCD-EFGH-1234-IJKL-5678-MNOP
• Product: PowerPath
• Capabilities: All

If powermt is not found, the package is not installed; if the key is missing or shows Capabilities: Base, multipathing/load-balancing is unlicensed and you must register a key with emcpreg -add <KEY> before continuing. To confirm the package itself is present on Solaris, query the package database:

pkginfo -l EMCpower

Step 2 — Configure PowerPath paths with powermt

Once licensed, ask PowerPath to discover and claim the SAN paths. The core sequence builds the path set, applies a policy, and saves the configuration so it survives a reboot:

1. Generate the configuration file from the current bus scan:
   powercf -q
2. Configure PowerPath devices from that file:
   powermt config
3. Set a load-balancing/failover policy for every device. co = CLARiiON Optimized:
   powermt set policy=co dev=all
4. Persist the configuration so it is reloaded at boot:
   powermt save
5. Display the result:
   powermt display dev=all

A correctly configured CLARiiON LUN looks like this — one pseudo name, a policy, an owning SP, and multiple alive paths:

On a real Solaris host the path device names are controller/target style (for example c3t500601234567890Bd0s0) routed through the Emulex (emlxs) or QLogic (qlc) HBA drivers. You should see at least one path to each storage processor (SP A and SP B) so that an SP failure does not take the LUN offline.

If powermt shows nothing

An empty powermt display dev=all usually means the configuration was never built or the bus has not been rescanned. Re-run the discovery cycle in order: powercf -q → powermt config → powermt set policy=co dev=all → powermt save → powermt display dev=all. If devices still do not appear after that, the LUNs are likely not zoned/masked to this host's HBAs, or the HBA driver did not bind the targets — verify SAN zoning and array storage groups, then open a storage support ticket rather than forcing it.

Step 3 — Confirm the pseudo devices appear to Solaris

PowerPath creates /pseudo/emcp@N nodes. They must show up in the Solaris format utility before any filesystem or volume manager can use them:

1. Run the disk formatter:
   format
2. In the AVAILABLE DISK SELECTIONS list, look for the emcpower entries, e.g.:
   • 16. emcpower0a <DGC-RAID5-0428 ...> /pseudo/emcp@0
   • 17. emcpower1a <DGC-RAID5-0428 ...> /pseudo/emcp@1
   • 18. emcpower2a <DGC-VRAID-0428 ...> /pseudo/emcp@2
3. Press Ctrl-C to exit format without changing anything.

The DGC vendor string identifies a Data General / CLARiiON LUN, so seeing DGC-RAID5 or DGC-VRAID pseudo devices confirms PowerPath has claimed the array disks. The raw c#t#d# paths for the same LUNs will also be listed — that is expected; you simply never address them directly.

Step 4 — Check whether the disks are already in a volume manager

If the host uses Veritas Volume Manager (VxVM), list the disks to see whether the PowerPath pseudo devices are already imported into a disk group:

vxdisk list

A configured layout shows the emcpowerNs2 slices belonging to a disk group with an online status, for example three SAN disks (emcpower0s2, emcpower1s2, emcpower2s2) all in the FCSQAgr disk group. In that listing, SVM means a disk is under Solaris Volume Manager, and a named group such as FCSQAgr is the Veritas disk group holding the SAN LUNs. If the pseudo devices appear online in a disk group, the storage is already configured and you can move to verification.

Step 5 — Confirm the filesystems use the PowerPath devices

Finally, confirm that mounted filesystems are actually carved from the PowerPath-backed volume group, not from a raw single path:

df -k

Look for a mount served from the Veritas device tree, e.g. /dev/vx/dsk/FCSQAgr/<volume> mounted on your application directory. In the source environment, the /MuhilTemp filesystem is cut from the PowerPath-protected disk group FCSQAgr, which is exactly what you want. Entries beginning with /dev/md/dsk/ are SVM metadevices (md = multidisk / RAID) for local OS slices, not your SAN data.

If the application data is not sitting on the PowerPath disk group, you must back up the data, remove the old layout, and recreate the volumes on the emcpower devices so that I/O is multipathed. Do this in a maintenance window and confirm backups first — recreating volumes is destructive.

Installation verification — proving multipathing works

After configuration, two commands prove the host is healthy and fault tolerant.

1. Verify PowerPath is active and HBAs are optimal

powermt display

This summarizes logical device counts per array type and lists each HBA. Every adapter should report an optimal summary with zero dead paths. A CLARiiON-attached host typically shows a non-zero CLARiiON logical device count and each HBA line ending in optimal.

2. Verify every path to a device is alive

powermt display dev=all

For each pseudo device you should see at least two active, alive paths split across both storage processors. The Mode column matters:

• active / alive — the path is licensed and carrying I/O. This is what you want.
• unlic / alive — the path is physically up but unlicensed, so PowerPath will not balance I/O across it. Register a full license to activate it.
• dead — the path is down; investigate the HBA, cable, SAN zoning, or SP.

If you see only one active path, redundancy is gone — fix the missing path before going live. If you see the error Bad dev value emcpowerN, or not under Powerpath control., PowerPath has not claimed that device and multipathing is not working; rerun the Step 2 configuration cycle.

Common pitfalls when you configure PowerPath on Solaris

• Confusing Solaris and Linux commands. On Solaris, paths are c#t#d#s# and the HBA drivers are emlxs/qlc; packages are managed with pkgadd/pkgrm. Linux-style device names such as sda/sdb, the qla2xxx driver, and yum belong to the Linux build of PowerPath — do not run them on a SPARC/Solaris box.
• Forgetting powermt save. Without it the configuration is lost on reboot and paths revert.
• Single-SP visibility. If all paths land on one SP, an SP failover or NDU will drop the LUN. Confirm paths to both SP A and SP B.
• Wrong failover mode on the array. CLARiiON/VNX LUNs must present the correct failover mode (ALUA = mode 4, or the legacy PNR modes) to match the PowerPath policy, or you get path thrashing.
• Addressing raw paths instead of the pseudo device. Always build filesystems/volumes on emcpowerN, never on an individual c#t#d# path.
• Unlicensed paths. A Base license claims the device but will not load-balance; you will see unlic paths until a full key is registered.

Back-out and roll-back procedure

If you must remove PowerPath, first move any data off the emcpower devices (deport the Veritas disk group or unmount the filesystems), then remove the package and reboot. On Solaris the correct removal command is the Solaris package tool, not yum:

1. Stop applications and unmount/deport storage on the pseudo devices.
2. Remove the PowerPath package:
   pkgrm EMCpower
3. Reboot the host so the OS rediscovers the raw paths:
   reboot

(The yum remove EMCpower.LINUX command from some runbooks applies only to the Linux build of PowerPath; it will not work on Solaris.)

The modern equivalent

Because EMC PowerPath for Solaris, the CLARiiON/VNX arrays, and Solaris 10 are all end-of-life, new deployments should not start here. On current Oracle Solaris, native multipathing is provided by MPxIO (Solaris I/O Multipathing), enabled with stmsboot -e and inspected with mpathadm list lu — no third-party license required. On a modern Dell/EMC array (PowerStore, Unity XT, PowerMax), use the array's current multipathing guidance, which favors native OS multipathing. The PowerPath workflow above remains the right reference only for legacy estates you are maintaining or migrating away from.

Key Takeaways

• PowerPath on Solaris collapses many Fibre Channel paths into one emcpower pseudo device for load balancing and failover.
• The configuration cycle is powercf -q → powermt config → powermt set policy=co dev=all → powermt save; always save so it survives reboot.
• Verify with powermt display (HBAs optimal, no dead paths) and powermt display dev=all (at least two active/alive paths across both SPs).
• Use Solaris tooling — format, vxdisk list, df -k, pkgrm — not the Linux equivalents like yum or sda device names.
• PowerPath and CLARiiON are EOL; new builds should use Solaris native MPxIO (stmsboot/mpathadm).

Frequently Asked Questions

How do I check if PowerPath is installed on Solaris?

Run powermt check_registration to confirm the license, and pkginfo -l EMCpower to confirm the package. If powermt is not found, PowerPath is not installed.

What does emcpower0a mean in the format output?

It is a PowerPath pseudo device (node /pseudo/emcp@0) that represents one SAN LUN across all of its physical paths. You build filesystems and volume groups on this device, never on the individual c#t#d# paths.

Why does powermt show a path as "unlic"?

The path is physically alive but unlicensed, so PowerPath will not load-balance I/O across it. Register a full PowerPath license (for example with emcpreg -add <KEY>) to activate it; a Base license alone will not enable multipathing.

How do I uninstall PowerPath on Solaris?

Move data off the pseudo devices, then run pkgrm EMCpower and reboot. Use pkgrm, not yum remove — the latter is for the Linux build only.

For more hands-on system administration and storage walkthroughs, subscribe to our YouTube channel @explorenystream.