WWN mapped to Veritas disk names

[DBPW]

I have some SAN disks that appear to Veritas VM 4.1 as "not setup". I
want to add them to a diskgroup that needs the space asap, but I
suspect they have data on them, so I want to check with my SAN admin
first.

The SAN admin won't understand the veritas disk names - c2t0d7xs2. Is
there a way I can see how Veritas maps its names to the WWNN or some
disk name the SAN (ESS) understands?

The OS (Solaris 10) doesn't seem to notice these disks: all the
"imported" SAN disks show up under the format command, but the ones
that are "not setup" do not.

[Dave]

try luxadm probe
if they don't show up, do a devfsadm then the luxadm probe

[DBPW]

Thanks Dave,
but no workee for me:

#> devfsadm
#> luxadm probe
No Network Array enclosures found in /dev/es
No FC devices found.

Veritas seems to be the only one to see these "Not setup"disks.
If it helps the ESS SAN is attached by Emulex FC HBA's, so I have
access to Emulex lputil and hbanywhere tools as well.

[Darren Dunham]

DBPW <mmc...@gmail.com> wrote:
> The SAN admin won't understand the veritas disk names - c2t0d7xs2. Is
> there a way I can see how Veritas maps its names to the WWNN or some
> disk name the SAN (ESS) understands?

Those aren't veritas names, it's from the OS.

The controllers are numbered sequentially as detected by the OS. You
can use the links in /dev/cfg to map from number to device.

The targets are mapped by the physical device driver. For instance a
SCSI device would have t equal to the SCSI target. Fiber drivers are
different. It depends on the specific driver. sometimes you can do
"hard binding" where you fix a particular WWN onto a target. "soft
binding" will just assign free targets to detected WWNs. The Sun
drivers will present a target equal to the WWN so it's pretty obvious.

If the disk is seen by the OS, you might be able to do an 'iostat -En'
and map the serial number from the device back to a physical or logical
device.

> The OS (Solaris 10) doesn't seem to notice these disks: all the
> "imported" SAN disks show up under the format command, but the ones
> that are "not setup" do not.

Can you show the output of 'vxdisk list'? VxVM shouldn't be able to use
disks that you can't see in 'format'. Perhaps they're left over from
some previous configuration.

Also what is the output of 'vxdisk list c2t0d7xs2' (or whatever one of
the devices is...)?

--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

[DBPW]

Thank you Darren,

> you might be able to do an 'iostat -En'
> and map the serial number from the device back to a physical or logical
> device.

The "not setup" disks do not appear in the listing of 'iostat -En'

Here's a partial list from ' vxdisk list', all the "not setup" disks
are shown as 'error', which I understand from from working with Veritas
before. I just want to be able to ask my SAN admin about these disks.

c2t0d16s2 sliced dkcsti92001 dgcsti920 online
c2t0d17s2 sliced dkdb2v701 dgdb2v7 online
c2t0d18s2 sliced dkdb2v801 dgdb2v8 online
c2t0d19s2 sliced dkfwserv9201 dgfwserv10 online
c2t0d20s2 sliced dkdb2v802 dgdb2v8 online
c2t0d76s2 sliced - - error
c2t0d77s2 sliced - - error
c2t0d78s2 sliced - - error
c2t0d79s2 sliced - - error
c2t0d80s2 sliced - - error
c2t0d83s2 sliced - - error

#> vxdisk list c2t0d76s2
Device: c2t0d76s2
devicetag: c2t0d76
type: sliced
info: privoffset=1
flags: online error private
errno: Device path not valid

[Dave]

Device path not valid means those devices no longer exist... OS won't
see them, and they are only entries in the Veritas DB/config left over
from something that was not removed properly

[DBPW]

It seems you are correct sir.

My SAN admin just added a few valid STK disks/LUNS. The output on the
"mystery disk" SAN disk is the same as the output of the valid SAN disk
from:

#> vxdisk list
DEVICE TYPE DISK GROUP STATUS
c2t0d23s2 sliced - - error

c2t0d76s2 sliced - - error

BUT, the output of the following is different.

#> vxdisk list c2t0d23s2
Device: c2t0d23s2
devicetag: c2t0d23
type: sliced
flags: online error private autoconfig
errno: Disk is not usable
Multipathing information:
numpaths: 2
c2t0d23s2 state=enabled type=secondary
c3t0d23s2 state=enabled type=primary

#> vxdisk list c2t0d76s2
Device: c2t0d76s2
devicetag: c2t0d76
type: sliced
info: privoffset=1
flags: online error private
errno: Device path not valid

Thank you, now I know.

[Darren Dunham]

Yup. If they were removed, you should be able to clear them from the
'vxdisk list' output with 'vxdisk rm <accessname>'

[ikom...@gmail.com]

If the disk has been renamed, use that command:
vxdisk -g [DG] list [DISK]

Device: DISK
devicetag: DISK
type: auto
hostid: localhost
disk: name=RENAMED_0 id=1364281024.6.localhost
group: name=DG id=1364281050.8.localhost
info: format=cdsdisk,privoffset=208
flags: online ready private autoconfig autoimport imported clone_disk thinrclm
pubpaths: block=/dev/vx/dmp/DISK char=/dev/vx/rdmp/DISK
guid: -
udid: HLK90F214505F0200a021beb0XX00%5F60050768028086FAC00000000000090F(THAT WWN)