EMC SAN connectivity to ES40

[roose]

Hi Folks,

Just wanted to check if somebody from the group has already experienced this problem that we are facing on our test server (ES40). This test server has been upgraded to VMS v7.3-2 from v7.3-1 on Sept. 2006, TCP/IP ECO v5.4 ECO5 and DECNet v7.3-2 ECO03, aggregate patch kit v0700. Our SAN is an EMC DMX2000.

On Jan. 16, our SAN admin presented to the system some new disks and we were able to see it after doing an mc sysman io auto. I was able to see the disks and was able to initiate it and copied some files to it. Just today, he presented again some new disks for another activity but we were not able to see it anymore after doing an mc sysman io auto. We then tried to do a server reboot, hoping that this will clear up the problem, as what we have done previously on our production system. However, after the reboot, not only we did not see the new devices, but even the disks that were presented to the system on Jan. 16 was no longer visible as well!

We have tried many attempts to correct this, i.e. doing wwid, re-zoning and re-masking the disks, but was still not able to see the devices once we boot. We tried minimal boot and booting using an OS binay disc but still the same. One thing that seems odd to us is that we seem to be able to see the disks from the console level i.e. wwid -show wwid, then init and show device, but once we boot up and do an mc sysgen auto, it will not come up.

I am attaching some pertinent data on our system for those who are interested in seeing this.

On the system side, the only major change that happened for the past days, after Jan. 16, was the upgrade of CA Peformance Manager to v2.4 SP3 and installation of its patches.

Hoping someone out there to help us on this. Thanks!

[EdgarZamora]

Perhaps this telling message from your attachment provides a clue?

P00>>>
P00>>> wwid pgb0.0.0.5.1 Link is down.
P00>>> wwid -show wwid
pgb0.0.0.5.1 Link is down.
[0] UDID:-1 WWID:01000010:6006-0480-0002-8775-0579-5359-4d30-3030 (ev:none)
[1] UDID:1165 WWID:01000010:6006-0480-0002-8775-0579-5359-4d34-3844 (ev:none)
[2] UDID:1166 WWID:01000010:6006-0480-0002-8775-0579-5359-4d34-3845 (ev:none)
[3] UDID:1177 WWID:01000010:6006-0480-0002-8775-0579-5359-4d34-3939 (ev:none)
P00>>> wwid -clear all
P00>>> wwid -show wwid
pgb0.0.0.5.1 Link is down.

I've actually never encountered this message before but it seems to me there's a problem here. I don't know if it's a physical problem or if you need to redo your wwids.
Have you checked your physical cabling?

[roose]

Yes, we did take a look into it. Initially, we have two HBA cards on the server, then after seeing this message and in the course of troubleshooting, we physically removed this HBA card so that we were now just using a single HBA card, but still the problem persisted after that.

[roose]

Did checked as well the physical cabling and per the SAN admin, it seems to be okay.

[EdgarZamora]

Hello Roose. Sorry I have to run and haven't looked closely. In the meantime if you could supply the output of wwidmgr -show ww -full and also wwidmgr -show r might prove useful.

[roose]

Is there any ES40 console parameter or SYSGEN parameter that will control how we can connect to our SAN disks?

[Robert Atkinson]

Roose, I don't know whether it applies, but I've seem similar problems on a HSG80 SAN when the SCSI level is not set to 3.

Is there anything similar on the EMC?

Could you also do a wwidmgr -show all

Rob.

[roose]

Hi Folks,

Thanks to those who replied.

This turned out to be a problem on the EMC side. It seems that for the EMC DMX2000, you can not assign LUN 0 for the VCMDB (a virtual device/database used for mapping the disks and servers), which is what we had on our box. They say that assigning LUN 0 for the VCMDB is a normal practice on their end, but somehow when they applied their latest microcode (firmware) on the box, it re-inforced this rule and affected how the VMS servers communicate with the SAN. This seems to be a unique rule for VMS on their end as they tried to assign the new disks on HP UX and Sun Solaris servers and these machines were able to see the disks. What they did was to re-assign their VCMDB with another value, and during our tests on our test server, it seem to have worked. Only thing to do now on our end is apply this on our production servers. Luckily, this did not affected those current disks that were already mapped on a running system, but only during a server reboot. Else, we would have got quite some problem on our end...

Regards,
Roose