— Kiaasa Dhanori Pune

To install and configure PowerPath on Solaris you confirm a valid license with powermt check_registration, build the pseudo (emcpower) devices with powercf -q and powermt config, set a failover policy, persist it with powermt save, and finally verify every path is active and alive. This guide walks through the complete workflow on a SPARC/Solaris host attached to an EMC CLARiiON or Symmetrix array, including how to integrate the multipath devices with Veritas Volume Manager and how to roll back cleanly.

EMC PowerPath (now part of Dell PowerPath) is host-based multipathing software that aggregates the multiple physical SAN paths to a LUN into a single, fault-tolerant logical device. If one Fibre Channel path, HBA, or storage-processor port fails, I/O continues on a surviving path with no application disruption. On Solaris that logical device is exposed as a pseudo device named emcpowerN.

Why use PowerPath on Solaris

A single SAN LUN is usually visible to the host through several paths — typically two HBAs cross-connected to two storage processors (SP A and SP B). Without multipathing software, Solaris would see the same disk multiple times (once per path) with no coordination, no load balancing, and no automatic failover.

PowerPath solves three problems at once:

• Path failover — automatically reroutes I/O when a path goes dead, keeping the LUN available.
• Load balancing — spreads I/O across active paths using a policy such as CLAROpt (optimized for CLARiiON) or Adaptive.
• Path management — a single pseudo device (emcpower0a) replaces a confusing list of cXtYdZ paths.

Modern note: Oracle Solaris and EMC/CLARiiON are legacy platforms. The CLARiiON family is end-of-life, and Solaris ships its own multipathing stack, MPxIO (Solaris I/O Multipathing / STMS), controlled with stmsboot and mpathadm. On Linux the equivalent is native device-mapper-multipath (multipath -ll). If you are building a new environment, prefer the native stack; the procedure below remains valid for the many production Solaris hosts still running PowerPath under support.

Pre-deployment requirements

Before you install and configure PowerPath on Solaris, confirm the prerequisites are in place. Getting these wrong is the most common cause of a configuration that "runs but sees no devices."

• Root access to the operating system (or sudo to root).
• At least one SAN LUN already zoned and masked to this host on the array, presented on two or more paths so multipathing has something to protect.
• A supported HBA and driver already installed (for SPARC this is typically the Emulex emlxs or QLogic qlc driver).
• The matching PowerPath package and a valid license key for your Solaris release and array type.

Step 1: Check the PowerPath installation and license

Never assume PowerPath is licensed just because the binaries exist. An unlicensed install will discover paths but mark them unlic and refuse to manage them. Confirm registration first:

1. Verify the license is registered:
   powermt check_registration
2. A healthy response shows a key and full capabilities, for example:
   Key XXXX-XXXX-XXXX-XXXX-XXXX-XXXX
Product: PowerPath
Capabilities: All

If the command is not found, or no key is listed, the product is either not installed or not licensed. Install the correct package for your platform and register the key with emcpreg -install before continuing. On a sysadmin team with a ticketing process, this is the point to raise a request to have PowerPath installed and the key applied.

Step 2: Configure PowerPath and build the pseudo devices

With a valid license in place, log in with your account, elevate to root, and inspect what PowerPath currently sees.

1. Become root:
   sudo su -
2. Display all PowerPath-managed devices:
   powermt display dev=all

A correctly configured LUN looks like this — note the pseudo name, the per-path Mode of active, and a State of alive across both storage processors:

If powermt display dev=all returns nothing, the pseudo devices have not been built yet. Reset and rebuild the PowerPath configuration in this order:

1. Rescan the buses and clear stale config:
   powercf -q
2. Build the pseudo devices from the discovered paths:
   powermt config
3. Set the load-balancing/failover policy on every device. co selects CLAROpt, the optimized policy for CLARiiON arrays:
   powermt set policy=co dev=all
4. Persist the configuration so it survives a reboot:
   powermt save
5. Confirm devices now appear:
   powermt display dev=all

Policy tip: use co (CLAROpt) for CLARiiON/VNX, so (SymmOpt) for Symmetrix/VMAX, and ad (Adaptive) as a general-purpose choice. Active/passive arrays in failover-only mode may report BasicFailover with only one active path per LUN by design.

Step 3: Confirm Solaris sees the emcpower disks

Once the pseudo devices exist, Solaris should list them through the standard format utility. This is how you confirm the OS layer — not just PowerPath — can address the LUNs.

1. Launch the disk utility:
   format
2. In the AVAILABLE DISK SELECTIONS list, look for entries named emcpower0a, emcpower1a, etc., backed by /pseudo/emcp@N. For example:
   16. emcpower0a <DGC-RAID5-0428 ...> /pseudo/emcp@0
3. Press Ctrl-C at the "Specify disk" prompt to exit without changing anything.

The DGC vendor string identifies a Dell/EMC CLARiiON LUN. You will also see the underlying raw cXtYdZ paths in the same list — that is expected; applications and volume managers should always be pointed at the emcpower pseudo device, never at a raw single path.

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

On most enterprise Solaris hosts the SAN LUNs are handed to Veritas Volume Manager (VxVM) or Solaris Volume Manager (SVM). Before you build anything, find out what is already there so you do not destroy live data.

1. List Veritas disks and their disk groups:
   vxdisk list

A correctly integrated setup shows the PowerPath pseudo slices (for example emcpower0s2) imported into a disk group with status online:

Here sandg is the Veritas disk group and the three emcpower slices are its members. Seeing the LUNs presented as emcpowerNs2 (rather than raw cXtYdZ) confirms VxVM is correctly stacked on top of PowerPath, which is exactly what you want for fault tolerance.

Note on DMP: Veritas has its own multipathing layer, DMP. When PowerPath is the chosen multipath provider, DMP should be configured to defer to it so the two do not conflict — the LUNs appear as single emcpower devices, not as multiple DMP subpaths.

Step 5: Confirm the filesystems are mounted on the PowerPath volume

The final integration check is to confirm the mounted filesystem actually lives on the PowerPath-backed disk group, not on a raw path.

1. List mounted filesystems and capacity:
   df -k
2. Look for a mount served by the Veritas device path, for example:
   /dev/vx/dsk/sandg/appvol   ...   /appdata

If the application filesystem is carved from the PowerPath disk group (as above), it inherits multipath fault tolerance automatically. In the df output you will also notice root and /var on /dev/md/dsk/dN — the md prefix is a Solaris Volume Manager metadevice (mirrored/RAID local disk), which is unrelated to the SAN. If your application data is not sitting on the PowerPath disk group, you must back it up, remove it from its current location, and recreate it on the PowerPath-backed group to gain the fault tolerance.

Step 6: Verify the installation end to end

After installation and configuration, run a final verification so you know multipathing is genuinely protecting I/O. This is the single most important step — a configuration that "looks done" but has a dead or unlicensed path provides no protection.

1. Get the host-level summary across all HBAs:
   powermt display
   Every HBA line should read optimal with Dead = 0. A non-zero dead-path count means a path, cable, or SP port is down.
2. Check every path on every device:
   powermt display dev=all
   Each path must show Mode = active and State = alive. At least two active paths per LUN is the goal — that is the redundancy that makes it fault tolerant.

Interpreting the path Mode column:

• active + alive — path is licensed, healthy, and carrying I/O. This is the target state.
• unlic — the path is alive but PowerPath is not licensed, so it cannot be used for load balancing or failover. Fix the license.
• dead — the path has failed; investigate the HBA, cable, switch zoning, or SP port.

If you see only one active path where you expect two, redundancy is compromised even though the LUN is still online — treat it as an incident, not a success. If you see the message Bad dev value emcpowerN, or not under Powerpath control, the device was never built and you should return to Step 2.

Common pitfalls when you install and configure PowerPath on Solaris

• Skipping the license check. The number one mistake. Paths show as unlic and no failover happens. Always run powermt check_registration first.
• Forgetting powermt save. Without it the configuration is lost on reboot and the host comes up with no emcpower devices. Save after every change.
• Pointing applications at raw paths. Mounting /dev/dsk/cXtYdZ directly bypasses PowerPath entirely — you lose failover. Always use the emcpower pseudo device or the VxVM volume on top of it.
• DMP and PowerPath fighting. Running Veritas DMP and PowerPath as two competing multipath providers causes duplicate device views and unpredictable failover. Let PowerPath own the paths and configure DMP to defer.
• Wrong policy for the array. Using co (CLAROpt) on a Symmetrix, or vice versa, leaves performance on the table. Match the policy to the array.
• Only one path zoned. If the SAN admin masked the LUN on a single fabric, PowerPath has nothing to fail over to. Verify two independent paths before declaring success.

Back-out and roll-back procedure

If the change must be reversed, remove the PowerPath software cleanly. On Solaris, PowerPath is a SVR4 package, so remove it with pkgrm rather than a Linux package manager:

1. Stop applications and unmount any filesystem on a PowerPath device, then deport the Veritas disk group if applicable:
   vxdg deport sandg
2. Remove the PowerPath package (the package name varies by version, e.g. EMCpower):
   pkgrm EMCpower
3. Reboot so the OS rediscovers the LUNs on their native cXtYdZ paths:
   init 6

Important correction: on a Solaris host you do not use yum remove EMCpower.LINUX — that is the Linux command and will fail on Solaris. The yum form applies only to RHEL/CentOS hosts. Use pkgrm on Solaris. After removal, reconfigure your filesystems against the native paths or your alternate multipath provider before bringing applications back online.

Key Takeaways

• Always run powermt check_registration first — an unlicensed install discovers paths but cannot fail over.
• Build pseudo devices with powercf -q then powermt config, set the right policy (co for CLARiiON, so for Symmetrix), and persist with powermt save.
• Verify with powermt display (HBAs optimal, Dead = 0) and powermt display dev=all (every path active + alive); two active paths per LUN is the goal.
• Stack volume managers on the emcpower pseudo device — never mount raw cXtYdZ paths, or you lose multipathing.
• Remove with pkgrm on Solaris (not yum), and for new builds prefer the native MPxIO/MPIO stack since CLARiiON and legacy Solaris are end-of-life.

Frequently Asked Questions

How do I check if PowerPath is installed and licensed on Solaris?

Run powermt check_registration as root. A healthy system returns a registration key, Product: PowerPath, and Capabilities: All. If the command is not found or shows no key, PowerPath is either not installed or not licensed, and any discovered paths will appear as unlic.

What does the emcpower device name mean?

emcpowerN is the PowerPath pseudo device — a single logical disk that represents all the physical SAN paths to one LUN. Applications and volume managers should always use this pseudo device (for example emcpower0a or the slice emcpower0s2) so that I/O automatically fails over and load-balances across the underlying paths.

How do I make the PowerPath configuration survive a reboot?

Run powermt save after building or changing the configuration. This writes the current device and policy state to PowerPath's persistent configuration file so the emcpower devices are recreated automatically at the next boot. Skipping it is a frequent cause of "the devices disappeared after reboot."

Is PowerPath still the right choice, or should I use native multipathing?

For existing, supported Solaris/EMC hosts, PowerPath remains valid and is well integrated with Veritas. For new deployments, both CLARiiON and legacy Solaris are end-of-life, so consider Solaris native MPxIO (stmsboot, mpathadm) or, on Linux, device-mapper-multipath (multipath -ll), which provide multipathing without a separate license.

If this walkthrough helped, subscribe to @explorenystream on YouTube for more hands-on system administration and storage guides.