Important Update: Cohesity Products Knowledge Base Articles


All Cohesity Knowledge Base Articles are now managed via the Cohesity Support Portal: https://support.cohesity.com/. The Knowledge Base articles available here will not reflect the latest information or may no longer be accessible.

DMP paths are not being enabled automatically after storage connection has been restored

Article: 100012120
Last Published: 2014-03-18
Ratings: 0 0
Product(s): InfoScale & Storage Foundation

Problem

In the event of a failure and restoration of a storage connection, the paths may not become enabled automatically and manual intervention will be required to re-enable them. Even running commands such as 'vxdctl enable' and 'vxdisk scandisks' did not re-enable the paths. In the end it was necessary to run the 'vxdmpadm enable' command for each of these paths.

 

Error Message

Breaking the Storage connection:

 
vxvm-udev:: device sdd with devno 8:48 has been removed. 
vxvm-udev:: device sdf with devno 8:80 has been removed. 
vxvm-udev:: device sdc with devno 8:32 has been removed. 
vxvm-udev:: device sde with devno 8:64 has been removed. 
vxvm-udev:: device sdb with devno 8:16 has been removed. 
vxvm-udev:: device sdg with devno 8:96 has been removed. 
kernel: VxVM vxdmp V-5-0-112 [Info] disabled path 8/0x40 belonging to the dmpnode 201/0x10 due to admin CLI kernel: 
kernel: VxVM vxdmp V-5-0-112 [Info] disabled path 8/0x20 belonging to the dmpnode 201/0x30 due to admin CLI kernel: 
kernel: VxVM vxdmp V-5-0-112 [Info] disabled path 8/0x60 belonging to the dmpnode 201/0x10 due to admin CLI kernel: 
kernel: VxVM vxdmp V-5-0-112 [Info] disabled path 8/0x30 belonging to the dmpnode 201/0x30 due to admin CLI kernel: 
kernel: VxVM vxdmp V-5-0-112 [Info] disabled path 8/0x10 belonging to the dmpnode 201/0x30 due to admin CLI kernel: 
 
 
After restoring the connection to the Storage, paths are seeing coming back online at the OS layer:
 
kernel: sd 1:0:0:0: [sdb] Write Protect is off 
kernel: sd 1:0:1:0: [sdc] Write Protect is off 
kernel: sde: 
kernel: sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA 
kernel: sdf3 sdf8 
kernel: sd 1:0:1:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA 
kernel: sde3 sde8 
kernel: sdc: 
kernel: sdb: 
kernel: sd 1:0:3:0: [sde] Attached SCSI disk 
kernel: sdd3 sdd8 
kernel: sdb3 sdb8 
kernel: sdc3 sdc8 
kernel: sd 1:0:4:0: [sdf] Attached SCSI disk 
kernel: sd 1:0:2:0: [sdd] Attached SCSI disk 
kernel: sd 1:0:0:0: [sdb] Attached SCSI disk 
kernel: sd 1:0:1:0: [sdc] Attached SCSI disk 
vxvm-udev: device sde with devno 8:64 has been added. 
vxvm-udev: device sdf with devno 8:80 has been added. 
vxvm-udev: device sdg with devno 8:96 has been added. 
vxvm-udev: device sdc with devno 8:32 has been added. 
vxvm-udev: device sdd with devno 8:48 has been added. 
vxvm-udev: device sdb with devno 8:16 has been added.
 
 
However if upon checking a disk using 'vxdisk list', the paths are still showing up as disabled:
eg.
numpaths: 6 
sdm state=enabled type=secondary 
sdk state=enabled type=primary 
sdl state=enabled type=secondary 
sdf state=disabled type=primary 
sdg state=disabled type=secondary 
sde state=disabled type=primary
 

Solution

Solution:

Once the latest VRTSaslapm was installed and the test repeated, the paths were then re-enabled automatically.

At the time of this issue, version 6.0.400.101 of the VRTSaslapm package was the latest available version on https://sort.Veritas.com/asl/latest


Applies To

RedHat 6.5

StorageFoundation 6.0.3 with HF 6.0.300.200

VRTSaslapm - 6.0.100.201

Was this content helpful?