Disk Arrays
cancel
Showing results for 
Search instead for 
Did you mean: 

EVA 4400 strange behaviour

andrei_cupa
Occasional Advisor

EVA 4400 strange behaviour

Hello All,

I have a problem with an EVA4400. Couple of days ago one cache battery died and, after that, my hp-ux boxes
couldn't see the disks any more:
ioscan -fn
target 9 0/4/1/1.1.0.0.0.0 tgt NO_HW DEVICE
ctl 7 0/4/1/1.1.0.0.0.0.0 sctl NO_HW DEVICE HP HSV300
/dev/rscsi/c6t0d0
disk 7 0/4/1/1.1.0.0.0.0.1 sdisk NO_HW DEVICE HP HSV300

In syslog:

May 6 12:41:37 xxxxxxxxx vmunix: 0/4/1/0: Device at device id 0x10000 is back in Name Server GPN_FT (FCP type)
May 6 12:41:37 xxxxxxxxx vmunix: response, and its 'Port World-Wide Name' remains the same as
May 6 12:41:37 xxxxxxxxx vmunix: original.
May 6 12:41:37 xxxxxxxxx vmunix: device id = loop id, for private loop devices
May 6 12:41:37 xxxxxxxxx vmunix: device id = nport ID, for fabric/public-loop devices
May 6 12:41:37 xxxxxxxxx vmunix: System will be able to see LUNs behind this port
May 6 12:41:37 xxxxxxxxx vmunix: (might need to run 'ioscan' first).

The same thing for all the hp-ux servers in the SAN, also on both HBA’s (0/4/1/0 and 0/4/1/1, all servers have 2 FC HBA’s)
I checked the SAN (cabling, switch configurations, no problems there) and still the same problem.

Curiously enough production still works (probably until the clusters will restart), we also have 2
MS WIN 2003 clustered in this SAN but they crashed.

Somebody advised me to update the firmware on the EVA4400 (recommended version 0090005000) but I cant access the storage using command view and I don’t know how to use the management port.

Did somebody else have a similar problem using eva?
10 REPLIES
Torsten.
Acclaimed Contributor

Re: EVA 4400 strange behaviour

Did you check the complete path from the server to the array controller (e.g. from the switch) - is the link there?

Hope this helps!
Regards
Torsten.

__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.

__________________________________________________
No support by private messages. Please ask the forum!

If you feel this was helpful please click the KUDOS! thumb below!   
Jozef_Novak
Respected Contributor

Re: EVA 4400 strange behaviour

Hello,

are you missing all HSV300 disks on the servers or just some ? It is possible that only some of the paths have failed.

Secondly, firmware upgrade via the management port on the EVA is not possible. You have to use Command View.

There was a whole bunch of problems reported with EVA4400 over the last few weeks. I suggest you start with opening a case at HP.

J.
andrei_cupa
Occasional Advisor

Re: EVA 4400 strange behaviour

The storage is still in use although i have those problems. This means that I have a link (This will last until the SG clusters will restart or some higher OS layer will notice the problem).

All the paths are affected and I was speaking about MFG port not the wocp port. Are you sure that using MFG port you can't update the firmware?

thanks in advance.
Víctor Cespón
Honored Contributor

Re: EVA 4400 strange behaviour

One battery failure should lead to the vdisks on the associated controller be switched to the other controller.
You would then see half the paths to each vdisk lost, but if you have a multipath software like SecurePath or have created multiple possible paths using PVlinks, the access to LUNs should not be lost.

The fact that you have lost access from Command View means that something else has happened. This requires an analysis of the EVA logs. Try to restart Command View service too.

Latest firmware for the EVA4400 is 095011000, you can also update the management module to 0001.2100, and you'll have Command View 9.01 inside there.
andrei_cupa
Occasional Advisor

Re: EVA 4400 strange behaviour

Yes I know what happens when a cache baterry failed that's why it is so wierd for me. I configured 5 EVA 4400 all of them had problems with cache batteries. I also use Secure Path and all the paths are active (the production on hp-ux boxes is still up). I restarted CV service at least 5 times :) also the SMA server. I will update the Management Module to see if i can upgdate controller firmware using cv 9.0.
Thanks for the ideea
andrei_cupa
Occasional Advisor

Re: EVA 4400 strange behaviour

I cant update the management module for using command view 9.0.1 because first i need to upgrade the firmware on the controllers ( i cant access command view on the SMA in order to do that).

Any other ideas?
Torsten.
Acclaimed Contributor

Re: EVA 4400 strange behaviour

CV needs to be working first - try to restart the services and/or contact HP for support.

Hope this helps!
Regards
Torsten.

__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.

__________________________________________________
No support by private messages. Please ask the forum!

If you feel this was helpful please click the KUDOS! thumb below!   
andrei_cupa
Occasional Advisor

Re: EVA 4400 strange behaviour

I can't get it working, maybe if I will use it as a DAS but then I will bring down production and I dont know how much downtime i will need.
Jozef_Novak
Respected Contributor

Re: EVA 4400 strange behaviour

Andrei,

if all paths were lost, even your Serviceguard would not be able to handle the problem. Once nothing is presented, even HPUX can not see the vdisks. More likely, you have lost only paths to one controller, as vcespon suggests.

Check:
# ioscan -fnC disk
# spmgr display

Your inability to access the EVA is a separate problem. Has already HP been informed ? (ISEE should have logged a call about CV being unable to manage the EVA).

J.
andrei_cupa
Occasional Advisor

Re: EVA 4400 strange behaviour

No paths are lost, I can ping each wwn from the switch. Also, if I shutdown one switch hp-ux boxes see the changes and autopath disables 2 paths out of 4.
I contacted HP, they will be here today I hope.