I have been performing an upgrade for a customer, using Solaris Live Upgrade to go from Solaris 10 update 2 to Solaris 10 update 10 and at the same time upgrade EMC powerpath from [an old version] to version 5.5

I am by no means a powerpath expert, but I am well aware of the issues with upgrading only the one without the other. The process I followed is:

  1. Live-upgrade Solaris
  2. Remove (pkgrm) powerpath from the ABE
  3. Comment out the powerpath dependent file systems in the ABE
  4. LUactivate and reboot
  5. Install PowerPath 5.5 P 01 B 2

The install finds the left-over power-path config and asks whether I want to upgrade it. On some of the 5 servers, the old version is PowerPath version 5.2, on others it was still running 4.5, but the result is the same for all of them.

At the end of the pkgadd it tells me the driver was successfully installed (it was) and tells me that no reboot is needed. However when I run powercf or powermt display I get an error stating Device(s) not found

Rebooting did not help. cfgadm looks as expected (Sorry I did not save the output), devfsadm -Cv did not create or remove any device links. The HBAs were linking (confirmed by luxadm -e probe as well as fcinfo hba-port)

format showed only the Solaris native links to the LUNs, with half of them in error state as expected due to them seen via both the avtive and passive path. mpathadm is not active.

After googling around I found a suggestion to look at the output of powermt display options to confirm that clariion management is enabled, and found that is says "unmanaged"... All other storage classes showed as "managed"

I then ran powermt manage class=clariion which returned an error stating incompatible initiator information received from the array

Despite this error I then got the emcpower devices and could see everything looking normal in powermt display dev=all. For good measure I followed this by powercf -q; powermt config; powermt save

I then un-commented the entries in /etc/vfstab and rebooted to make sure all was ok. I then ended up with a system in single-suer mode with filesystems/local in maintenance. I discovered with a lot of testing that I had to redo the powermt manage class=clarion procedure after every reboot.

For now I have reverted to the old pre-upgrade ABE. Everything is still working perfectly when I moved back to the old versions of Solaris and PowerPath.

  • Best suggestion is to work with EMC on this.
    – mdpc
    Commented Feb 19, 2013 at 20:56
  • I can not work with EMC on this now as the support on the Clariion has expired. I can see 3 options right now. a) Try another version of PowerPath to see if it works. Unfortunately v5.5.01.2 seems to be the latest supported for Solaris 10. b) Provision VNX luns and confirm that it doesnt have the same issue. In this case I will have to complete the migration quickly and get rid of dependencies on the old Clariion. c) Re-install PowerPath 5.5 using a fresh install, eg without importing the "old" configuration. Option cis simplest so I will do that first.
    – Johan
    Commented Feb 20, 2013 at 8:58
  • I have had success using PowerPath version 5.3. I still need to perform more testing to confirm my findings.
    – Johan
    Commented Feb 21, 2013 at 8:50

2 Answers 2


I did the following and it worked:

Although the Solaris OS can distinguish between FC and iSCSI devices, PowerPath 5.5 does not make this distinction for manage and unmanage. The mpxio-disable value must be set to yes in both the fp.conf and iscsi.conf files for PowerPath to manage the following storage arrays:



Hitachi USP and HP StorageWorks EVA 3000/5000/8000

Arrays listed in scsi_vhci.conf

See page 35 of the "Installation and Administration guide" for EMC PowerPath for Solaris for more details. The "Determine if arrays are managed by PowerPath or MPxIO" chapter provides the details. When "mpxio-disable=yes" statement is missing from iscsi.conf file, VNX class is implicitly managed by MPxIO. Since there is no explicit statement to manage the class (the VNX class did not exist in the previous release), the new VNX becomes "unmanaged".

  • I strongly suspect that this is exactly the issue that I had. Unfortunately I can not test it easily - the customer is satisfied with their "working solution" based on the older EMC powerpath software.
    – Johan
    Commented Jul 20, 2013 at 15:20

In addition to the /kernel/drv/iscsi.conf mpxio-disable=yes is missing, I also found that the emcpower devices become incorrectly numbered post PP5.5 upgrade and reboot. Luckily I had taken a backup of my mappings prior to the work which I was then able to restore from.

$ /opt/EMCpower/bin/emcpadm export_mappings -f emcp_exports.txt     <--backs up the Mapping
$ /opt/EMCpower/bin/emcpadm import_mappings -f emcp_exports.txt  <-- restores the mappings

Then save your config:

$ powermt save
  • I can only hope I will remember to come look at this all when I do upgrade powerpath again. I am getting too old for all this.
    – Johan
    Commented Jul 20, 2013 at 15:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .