Firstly, please refer to http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/scanning-storage-interconnects.html for some pre-checking, like memory usage, sync etc.
Then, we should scan for new disk connected to hba one by one(issue_lip, Scenario:fabric on Linux with Emulex hbas), we should check dmpnodes are ALL in ENABLED state before moving on to another hba. This is because when scanning for new disks, we expect to result in disabling paths on that controller – and moving on only when the paths are confirmed enabled again. And during all procedures, tail -f /var/log/messages would help.

1) Checked the messages file for any existing issues. Identified and eliminated concerns of I/O error messages which have occured for some time:
May 29 04:11:05 testserver01 kernel: end_request: I/O error, dev sdft, sector 0^M
May 29 04:11:05 testserver01 kernel: Buffer I/O error on device sdft, logical block 0^M
May 29 04:11:05 testserver01 kernel: end_request: I/O error, dev sdft, sector 0^M
/var/log/messages.1:May 27 22:48:04 testserver01 kernel: end_request: I/O error, dev sdjt, sector 8
/var/log/messages.1:May 27 22:48:04 testserver01 kernel: Buffer I/O error on device sdjt3, logical block 1
2)Saved some output for comparison later:
syminq -pdevfile > /var/tmp/syminq-pdevfile-prior
We expected device as hyper 2C27 so I looked for this device in the output and, as expected, did not find it.
vxdisk -o  alldgs list > /var/tmp/vxdisk-oalldgs.list
3)Checked the current state of the vm devices dmp subpaths:
for disk in `vxdisk -q list | awk ‘{print $1}’`
do
echo $disk
vxdmpadm getsubpaths dmpnodename=${disk}
done | tee -a /var/tmp/getsubpaths.out  Read more…