Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
Best suggestion is to work with EMC on this. –  mdpc Feb 19 '13 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 Feb 20 '13 at 8:58
    
I have had success using PowerPath version 5.3. I still need to perform more testing to confirm my findings. –  Johan Feb 21 '13 at 8:50

2 Answers 2

up vote 1 down vote accepted

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:

EMC VNX

EMC CLARiiON

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".

share|improve this answer
    
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 Jul 20 '13 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
share|improve this answer
    
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 Jul 20 '13 at 15:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.