Vxvm 3.5 无法识别到SUN 3310

sunyeait

Vxvm  3.5 无法识别SUN 3310

主机：
    V440 本机四块硬盘
外设：
       DAT72 ：SG-XTAPDAT72-D
存储3310: (firmware:3.25W)
SG-XPCI2SCSI-LM320
软件:solaris 9 04/4+最新补丁  ；VxVM 3.5 + patch +  VRT3310（3310asl-1_0-solsparc

规划：
    SUN 3310  6*73G  disks，one logic raid 5 drive ，划分为two luns ,SB方式；

现状：
   V440 format 可识别到本机四块硬盘及两LUN，可进行正常挂卸载且能正常读写；但VxVM无法发现两lun(通过vxinstall初始化，无发现此存储；通过vxdiskadd强行加入，提示no matching disks……通过vxdisk list也无显示；

解决办法：
升级SUN 3310 firmware 3.25W至firmware 4.11，patch:113722-12;对V440 boot –r便可！

参考文档：
   
Document Audience:
SPECTRUM
Document ID:
71046
Title:
VERITAS Volume Manager 3.x/4.x: Unable to Recognize Newly-Added Disks.
Update Date:
Tue May 10 00:00:00 MDT 2005

Products:
VERITAS Volume Manager 3.5 Software,  VERITAS Volume Manager 4.0 Software

Technical Areas:
Software Troubleshooting

Keyword(s):volume manager, vxvm, recognize disk, 3310
Problem Statement:

Top

I've added some new disks to my host, and Solaris[TM] can see the disks
with the 'format' utility, but VERITAS Volume Manager (VxVM) does
not list them.
Resolution:

Top

Here are a few reasons why this occurs:
-----------------------------------------------------------------------------------------
The command 'vxdctl enable' should be run to rescan the
host for any newly-added disks.
-----------------------------------------------------------------------------------------
The disk(s) must have a valid VTOC on them. Use the
'format' command to label them if they have not been
labeled yet.
-----------------------------------------------------------------------------------------
Make sure the disk(s) have a slice 2 labeled as "backup"
as shown in 'format' output. Without this slice, VxVM
will not recognize the disk.
-----------------------------------------------------------------------------------------
On VxVM 3.1.1 and above, run the command:
# vxdmpadm listexclude

This is done to make sure that the controller(s) or disk(s) in
question have not been excluded or suppressed.
-----------------------------------------------------------------------------------------
Volume Manager must be able to do a SCSI inquiry on the device in order to
get it's product information. If VxVM is unable to successfully run the
ioctl, it will not recognize the disk. You can run the SCSI inquiry ioctl
manually by running:
# /usr/lib/vxvm/diag.d/vxdmpinq  /dev/rdsk/c#t#d#s2

If there is a failure, like the one shown here:
ioctl failed: I/O error
VxVM vxdmpinq ERROR V-5-1-8853 /usr/lib/vxvm/diag.d/vxdmpinq for
       /dev/rdsk/c2t0d0s2. ioctl failed., evpd 0 page code 0. I/O error

this is most likely the cause. You can also use the Solaris command
'format' to run a SCSI inquiry. Begin by running:
# format -e /dev/rdsk/c#t#d#s2

Select the 'inquiry' command. You will either see the inquiry
information for the disk, or, in this case, a failure to retrieve this
information:
format> inquiry
Failed

If the SCSI inquiry fails, it is related to a hardware problem of some
sort, and the troubleshooting for this problem should shift from a VxVM
problem to a device problem. One instance of this problem with failed
SCSI inquiry commands was found to exist on a Sun StorEdge[TM] 3310 (SE3310)
when attached to the internal SCSI port of the Sun Fire[TM] V440 host. The
firmware on the array, which was not at the correct revision, was upgraded,
the SCSI inquiry problem was solved, and VxVM could recognize the disk.
[*Bug ID 4929829 addresses the 3310 firmware issue where inquiry return fails
and Volume Manager does not see the LUN.]
The 3310 firmware version which fixes this issue is 325W (PATCH
113722-07
) and
once the firmware is applied, the inquiry data returns correctly, allowing
Volume Manager to access the LUNs. Relabelling of the LUNs may be necessary.
-----------------------------------------------------------------------------------------
A rare case could be caused by some old/duplicate entries in
the /dev/vx/dmp and /dev/vx/rdmp directories. To check if this is
the cause, look in these two directories for any devices with the
same major/minor number combinations. In this example, most entries
have been removed for brevity:
# ls -l /dev/vx/dmp

/dev/vx/dmp:
total 0
......
brw-------   1 root   root   243,560 Aug  7 13:26 c10t0d0s0
brw-------   1 root   root   243,561 Aug  7 13:26 c10t0d0s1
brw-------   1 root   root   243,562 Aug  7 13:26 c10t0d0s2
brw-------   1 root   root   243,563 Aug  7 13:26 c10t0d0s3
brw-------   1 root   root   243,564 Aug  7 13:26 c10t0d0s4
brw-------   1 root   root   243,565 Aug  7 13:26 c10t0d0s5
brw-------   1 root   root   243,566 Aug  7 13:26 c10t0d0s6
brw-------   1 root   root   243,567 Aug  7 13:26 c10t0d0s7
......
brw-------   1 root   root   243,560 Jul 27 09:31 c3t9d16s0
brw-------   1 root   root   243,561 Jul 27 09:31 c3t9d16s1
brw-------   1 root   root   243,562 Jul 27 09:31 c3t9d16s2
brw-------   1 root   root   243,563 Jul 27 09:31 c3t9d16s3
brw-------   1 root   root   243,564 Jul 27 09:31 c3t9d16s4
brw-------   1 root   root   243,565 Jul 27 09:31 c3t9d16s5
brw-------   1 root   root   243,566 Jul 27 09:31 c3t9d16s6
brw-------   1 root   root   243,567 Jul 27 09:31 c3t9d16s7
......

Notice how both disks (c10t0d0 and c3t9d16) have the same minor numbers. No two devices in these directories should have the same
minor numbers. If they do, this could be the cause of the problem.
To remedy this situation, simply remove ALL the entries with the following:
# rm /dev/vx/dmp/*
# rm /dev/vx/rdmp/*

Reboot. These devices will be created correctly with just a simple
reboot ('boot -r' is not needed).
-----------------------------------------------------------------------------------------
Sometimes, VxVM actually does recognize the disk, but mistakenly
believes that it is simply another path to another disk, so not all
the disks show up in a 'vxdisk list' output. For example, if you add
three new disks (say, c3t0d0, c4t0d0, and c5t0d0) to a system, but
VxVM only lists one of them on a 'vxdisk list' output as follows:
DEVICE       TYPE      DISK         GROUP        STATUS
c3t0d0s2     sliced    -            -            error

it might be because DMP is mistaking the three disks for three paths
to the same disk. You could verify this by running the following:
# vxdisk list c3t0d0s2

Look at the pathing information at the bottom of the output:
Multipathing information:
numpaths:   3
c3t0d0s2        state=enabled   type=primary
c4t0d0s2        state=enabled   type=primary
c5t0d0s2        state=enabled   type=primary

As you can see, DMP believes these three disks are one single disk
with three paths. This is typically because the disks are presenting
the same serial number to Solaris, or something else is wrong on the
array causing the multi-pathing software to act incorrectly. In all
cases, this behavior is caused by some error on the array or disks.


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/832/showart_104716.html