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.

Ramdev

Ramdev

I have started unixadminschool.com ( aka gurkulindia.com) in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' unixadminschool.com. You can connect me at - https://www.linkedin.com/in/unixadminschool/

What is in your mind, about this post ? Leave a Reply

Close
  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us