How can I safely reset the PowerPath config ?

That's about th same what I was thinking. But thanks for your comment

I'll step aside from answering if your colleague's approach is sound, and leave that to others.

HPUX is one of the most reliable UNIX systems I know of.  If it is losing a path, than either something is going wrong with the hardware on the server or somewhere else within the connectivity structure (and that can include a person).  If it's on the server a simple replacement of the HBA will help address the problem on the HPUX box.

What I am saying is there is a problem..........fix the problem!  Stop being re-active and try to be pro-active (albeit after the fact...)

You will never fix a problem by attempting to treat a sympton, you treat the problem.

Check the HBA, check the cable, check the ports, check if someone is trying to configure something they have no clue to what they are doing.  Go and talk to folks, look at logs, cause this error got reported somewhere.  I know HPUX, there would have been a message.  If it's not on HPUX, then check the network involved.

Just a thought,

Rita

HPUX does not create special PowerPath device files like AIX/Linux does,  so i am not even sure what powermt remove will do, maybe just stop load balancing. I remember we used to set pv timeout to 180 seconds. (pvchange -t 180) but even if you lost a path temporarily ..ioscan should have brought it back. Something is fishy.

This solution was dug up by a colleague of mine and I'm not even sure if it's a good idea to touch PPath in the first place, you're right about that.

It's an a) HP Blade server or b) bladecenter issue OR an issue with the c) SAN OR an issue with a certain d) storage port.

a) blade server: could it be a firmware issue ? Or a PPath version ?

b) blade center: could it be a firmware issue ? An MDS9124e issue ? Other servers in the same blade center using the same switches are working just fine.

c) SAN: other servers keep on functioning using all available paths and since zones cannot disappear and come back just like that, especially since after a reboot everything is fine again.

d) Storage: since other servers can still use all ports, it's not a connectivity issue. Could it be a problem with the Navisphere Agent ? Is network connectivity a must in this ?

Having said all this, I think the Navi Agent could be an important thing to look at or the PowerPath version.

any bit errors on the MDS port ?

nope. Not a single one ! On every port from "server - 9124e - 9222i - 9134 - Clariion". I asked for an EMCGRAB. I think we should wait for the outcome of that. HEAT will hopefully tell us more infor. I'll let you know what we will find.

Hello,

   Just wondering why a erboot works, but an ioscan doesnt, a reboot would force a re-login to the switch/SAN, which an ioscan would not. If the path goes again, would it be worth trying to block/unblock the port on the switch (forcing a re-login at SAN/switch level) then try an ioscan?

If that works, I'd look at the SAN or GBIC on switch as a possible issue.

Hope this helps,

    Nollaig

These are HP Blade servers, connected to two 9124e switches, so internal ports. Other servers don't have this issue at all.

I'm still waiting for the EMCGRAB outputs.

I will keep this posts up2date when I know more.

monitor the `fcmsutil /dev/xxx stat` and compare with a working one. You might see the count values high on the problem one

If powerpath is not bringing a path back to Alive state when physical path is alive, i think you should call support and get it checked.

the powermt remove dev=all, i dont think you can remove devices from the PP if the PP sees an active paths to the devices.. I have not tried on the HPUX if it allows it.. let me leave it to PP and HPUX experts to answer

Regards,

Saurabh

Yeah, me too. We created a SR. Let's see what EMC support thinks of this.

Hello RRR,

    Was just wondering if you could get a copy of the powermt display dev=all before a path loss and reboot and after.

I would be interested in seeing if the H/W path changed after the reboot in any way.

Regards,

   Nollaig

I just asked gthe customer to get me the EMC GRABS. Let's wait for the output of that first.

I finally got the EMCGRABS. It turned out that on both HPUX machines the path to A0 had an error and came back online, but the path to B1 didn't recover. A0 and B1 are in the same fabric, so I suspect an error has occurred in that fabric and the other fabric simply stayed alive.

The thing is: why did the HPUX path to A0 recover and B1 didn't ? We opened a SR for this issue, since IMHO this could easily be a host registration issue on the Clariion, but perhaps a driver issue on HPUX as well.

Thanks, keep us posted!