VXVM : Unable to recognise newly-added disks
VERITAS Volume Manager 3.x/4.x: Unable to Recognize Newly-Added Disks.
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 that 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
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. The ioctl can be run manually as follows:
# /usr/lib/vxvm/diag.d/vxdmpinq /dev/rdsk/c#t#d#s2
Example of a typical failure:
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
A SCSI inquiry can also be done in the Solaris O/S command ‘format’. Begin by running:
# format -e /dev/rdsk/c#t#d#s2
Select the ‘inquiry’ command. It will either show the inquiry information for the disk, or, as in this example, a failure to retrieve it:
format> inquiry Failed
If the SCSI inquiry fails, it is related to a hardware problem of some sort, and the troubleshooting focus should shift from a VxVM problem to a device problem.
One instance of this problem with failed SCSI inquiry commands, was found on a Sun StorEdge[TM] 3310 SCSI Array, when attached to the internal SCSI port of a Sun Fire[TM] V440 host. When 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.
This issue(where inquiry fails, and Volume Manager does not see the LUN), is fixed in the SE3310 SCSI Array firmware version 325W and once the firmware is applied, the inquiry data returns correctly, allowing Volume Manager to access the LUNs. Relabelling the LUNs may be necessary.
Rarely, the cause could be some old or duplicate entries in the /dev/vx/dmp and /dev/vx/rdmp directories. To check, look in these two directories for any devices with the same major/minor number combinations. In the following 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 commands:
# 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 newly-added disk, but mistakenly believes it is simply another path to a known disk, so not all the disks show up in a ‘vxdisk list’ output.
For example, if three new disks (c3t0d0, c4t0d0, and c5t0d0) were added to a system, but VxVM only lists one of them in the ‘vxdisk list’ output:
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. 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 can be seen, 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 the Solaris O/S, 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.
Certain devices on EMC arrays, such as the “GateKeeper” and “Volume Logix Database” devices, are intentionally masked by certain versions of VxVM if the EMC array support library ( ASL ) is installed.
In certain situations with VxVM 4.x (without patch), newly-created LUNs on SE99xx, EMC, or third-party storage, are seen from the Solaris format command, but VxVM cannot see them (also after executing the “vxdctl enable” commmand or rebooting the system). The LUNs are not seen in the output of the “vxdisk list” command.
To remedy this situation, perform the following commands:
# rm /etc/vx/disk.info* # rm /dev/vx/dmp/* # rm /dev/vx/rdmp/* # reboot
This relates to the Persistent Device Naming feature, introduced in VxVM 4.1.