System Administration
cancel
Showing results for 
Search instead for 
Did you mean: 

11.23 won't see 9th and 10th LUNs on EMC VNX SAN

 
ridgetop01
Occasional Visitor

11.23 won't see 9th and 10th LUNs on EMC VNX SAN

We have a system running HP-UX B11.23 (but we are Solaris admins!) which is currently accessing 10 Clariion CX3-20cWDR5 (that's how the system identifies them) LUNs at designations:

 

/dev/dsk/c29t0d0

/dev/dsk/c29t0d1
/dev/dsk/c29t0d2
/dev/dsk/c29t0d3
/dev/dsk/c29t0d4
/dev/dsk/c29t0d5
/dev/dsk/c29t0d6
/dev/dsk/c29t0d7
/dev/dsk/c29t1d0
/dev/dsk/c29t1d1

 

and also /dev/dsk/c31*, /dev/dsk/c25*, /dev/dsk/c27* designations - 2 controllers, 2 service processers per path.

 

The SAN admins added 10 new LUNs on a VNX device, all configured the same, and the system sees 8 of those at:

 

/dev/dsk/c3t0d0 -> /dev/dsk/c3t0d7 and /dev/dsk/c33t0d0 -> /dev/dsk/c33t0d7

 

but it refuses to see the last two, which should probably be at /dev/dsk/c3t1d* and /dev/dsk/c33t1d*.

 

I've tried everything (REPEATEDLY) except rebooting to get it to see them, to no avail. Is there some magic that will make that target number roll over from target 0 to target 1 and make those LUNs available? We are getting desperate - is there some magic that is needed here beyond the usual ioscan/insf/pvcreate/powermt commands to make this happen?

 

=======================

Possible clue - I do see a device file on the system using /dev/dsk/c3t1 - perhaps it can't roll because of this old device file which seems unused?

 

# ls -l /dev/dsk/*t1*

:

brw-r----- 1 bin sys 31 0x031000 Dec 10 2007 /dev/dsk/c3t1d0

 

There is no c33t1* file, but perhaps this one is enough to block somehow? There doesn't seem to be anything using this device file, but I don't know enough to be sure of that.

 

* how can I find out if it's used?

* how should I remove it if that's an appropriate response??

 

TIA for any help you can offer

1 REPLY
Judith Reed
Occasional Visitor

Re: 11.23 won't see 9th and 10th LUNs on EMC VNX SAN

Ok, this problem resolved itself when I killed the naviagent process (EMC package that intereracts with arrays) which had been running since July 17 of last year and restarted it via:

 

# /opt/Navisphere/bin/naviagent -f /etc/Navisphere/agent.config

 

And, the devices came back looking like:

 

disk 4 0/7/1/0.12.1.0.0.0.0 sdisk CLAIMED DEVICE DGC VNX5600WDVR
/dev/dsk/c34t0d0 /dev/rdsk/c34t0d0

 

with VNX5600WDVR instead of VRAID designation. And, I got the two add'l devices, for a total of 10, with the 2 add'l at target 1.

 

Glad it's over with, but very surprised that something as seemingly innocuous as that naviagent process would have such an overwhelming ability to mess everything up.

 

Thanks...