vxdmp: NOTICE: VxVM vxdmp V-5-0-112 [Warn] disabled path 118/0x88 belonging to the dmpnode 321/0x8 due to devid mismatch

book

Article ID: 100013278

calendar_today

Updated On:

Description

Error Message

hostname vxdmp: WARNING: VxVM vxdmp V-5-3-1970 dmp_verify_devid:Graceful DR steps are not followed by the user on the path 118/0x88. The device with old serial number
ven.000122334455667788991122000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000
is replaced with a new device with serial number
naa.60000970000122334455667788991122

hostname vxdmp: NOTICE: VxVM vxdmp V-5-0-112 [Warn] disabled path 118/0x88 belonging to the dmpnode 321/0x8 due to devid mismatch

Cause

The Data Corruption Prevention Activation (DCPA) is a DMP feature that is designed to prevent data corruption that is caused by using incorrect dynamic reconfiguration procedures to change the paths to disks, "underneath" a DMP device.


Background

dmp_verify_devid is an enhancement to the DCPA feature. Starting with Storage Foundation 6.1, DMP will now record the device IDs that are reported by individual paths in the kernel. If any dynamic reconfiguration events are detected by DMP, before making any change to the in-kernel DMP database, DMP will first compare the recorded device IDs against the latest device IDs reported by the paths. If there is any discrepancy, DMP will refuse to update the in-kernel DMP database, and the offending paths will be disabled to prevent data corruption. System messages will also be logged, like the ones in the Error field of this article, with the old and new serial numbers (device IDs) reported by the path. We can confirm that the underlying disk device has been changed by comparing the old, and new, serial numbers.

In some cases, the underlying itself disk device is not changed, but the reported device ID is changed. For the example listed in the Error field of this article, the device was not changed, but the reported device ID was changed.

ven. 00012233445566778899112200000..... (aligned the numbers)
naa.60000970000122334455667788991122


If this happens, then the disk array vendor should be contacted to determine why the device ID changes.

The device ID is derived from the SCSI Inquiry Page 131 (Hex 0x83). The data can be retrieved by using the vxscsiinq command.


Example 1

# vxscsiinq -e 1 -p 131 /dev/rdsk/c1t50060E80004372C0d12s2Inquiry for /dev/rdsk/c1t50060E80004372C0d12s2, evpd 0x1, page code 0x83/dev/rdsk/c1t50060E80004372C0d12s2: Raw data size 34Bytes 0 - 9 0x00 0x83 0x00 0x1e 0x02 0x01 0x00 0x14 0x48 0x49Bytes 10 - 19 0x54 0x41 0x43 0x48 0x49 0x20 0x44 0x36 0x30 0x30Bytes 20 - 29 0x34 0x31 0x32 0x34 0x30 0x34 0x35 0x32 0x01 0x10Bytes 30 - 33 0x00 0x02 0x30 0x30


With more recent versions of Volume Manager, the contents of the page are also parsed. 

Example 2
# ./vxscsiinq -e 1 -p 131 /dev/sdgvInquiry for /dev/sdgv, evpd 0x1, page code 0x83------- Identifier Descriptor 1 -------ID type             : 0x0 (Vendor specific)    Protocol Identifier : 0x60Code set            : 0x0PIV                 : 0x0Association         : 0x0Length              : 0x70Data                : 0002987009165330303733380000000000000000...        /dev/sdgv: Raw data size 20Bytes:   0 -   7    0x00  0x83  0x00  0x10  0x60  0x00  0x09  0x70  ....`..pBytes:   8 -  15    0x00  0x02  0x98  0x70  0x09  0x16  0x53  0x30  ...p..S0Bytes:  16 -  19    0x30  0x37  0x33  0x38                          0738# ./vxscsiinq -e 1 -p 131 /dev/sdevInquiry for /dev/sdev, evpd 0x1, page code 0x83------- Identifier Descriptor 1 -------ID type             : 0x3 (NAA)Protocol Identifier : 0x0Code set            : 0x1PIV                 : 0x0Association         : 0x0Length              : 0x10Data                : 60000970000298700916533030373338------- Identifier Descriptor 2 -------ID type             : 0x4 (Relative target port)Protocol Identifier : 0x0Code set            : 0x1PIV                 : 0x0Association         : 0x1Length              : 0x4Data                : 000000a6        /dev/sdev: Raw data size 32Bytes:   0 -   7    0x00  0x83  0x00  0x1c  0x01  0x03  0x00  0x10  ........Bytes:   8 -  15    0x60  0x00  0x09  0x70  0x00  0x02  0x98  0x70  `..p...pBytes:  16 -  23    0x09  0x16  0x53  0x30  0x30  0x37  0x33  0x38  ..S00738Bytes:  24 -  31    0x01  0x14  0x00  0x04  0x00  0x00  0x00  0xa6  ........
 

Resolution

  • If the underlying disk paths are actually changed, follow the documented procedure in the Storage Foundation Administrators Guide to remove the LUNs and add them back again. This guide also contains information about the correct, dynamic LUN removal and addition procedures.

In particular, the following chapters of the Storage Foundation Administrators Guide are recommended:

From the Storage Foundation Administrators Guide for 6.0, and 6.1:
Chapter 10 - Dynamic Reconfiguration of devices

From the Storage Foundation Administrators Guide for 6.0:
Chapter 9 - Administering Dynamic Multi-Pathing
Chapter 10 - Dynamic Reconfiguration of devices

From the Volume Manager Administrators Guide for 5.1 SP1:
Chapter 5 - Online Dynamic Reconfiguration

This documentation is available from Veritas SORT:
https://sort.Veritas.com/documents
 

  • If the underlying disk paths are unchanged, and only the SCSI Inquiry Page 131 data are changed, contact the disk array vendor to verify that the disk array is configured correctly. Confirm that it is accurately reporting unique disk device identifiers.

    When describing the problem to the disk array vendor technical support, please emphasize the following to minimize confusion:

    • If the disabled paths do not have any I/O failures, then it should not be necessary to check for disk I/O errors. There will most likely be none.
    • DMP disables the paths because the SCSI Inquiry Page 131 (Hex 0x83) reported different contents than those reported when the path was first claimed by DMP. DMP concluded that the path then pointed to a different disk and disabled the path to prevent data corruption.  
    • Ask the disk array vendor to determine why the contents of SCSI Inquiry Page 131 changed.  
    • Ask the disk array vendor to ensure that SCSI Inquiry Page 131 reports the same data contents across all the paths of the same LUN.
    • Ask the disk array vendor to ensure that SCSI Inquiry Page 131 data contents remain the same at all times, and do not change spontaneously.

Issue/Introduction

DMP disables a disk path because the device ID that is reported through the path has changed.

Additional Information

UMI: V-5-0-112