VxVM not able to see new disk

Linux and Unix-Like Emergency UNIX and Linux Support
1

I have VxVM 5.1 running on Solaris-10. I have to increase a application file-system and storage team gave me a lun. After scanning scsi port by cfgadm, I can see them in format output. I labelled it, but I am not able to see them in "vxdisk list".
I already tried commands -->

vxdctl enable
vxconfigd -k
vxdisk scandisks

query can see new disk

root@pr_ora_db16:/# prtvtoc /dev/rdsk/c3t5006048AD5315569d1245s2
* /dev/rdsk/c3t5006048AD5315569d1245s2 partition map
*
* Dimensions:
*     512 bytes/sector
*     128 sectors/track
*      15 tracks/cylinder
*    1920 sectors/cylinder
*    9525 cylinders
*    9523 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      2    00          0    263040    263039
       1      3    01     263040    263040    526079
       2      5    01          0  18284160  18284159
       6      4    00     526080  17758080  18284159
root@pr_ora_db16:/# /usr/lib/vxvm/diag.d/vxdmpinq /dev/rdsk/c3t5006048AD5315569d1245s2
Inquiry for /dev/rdsk/c3t5006048AD5315569d1245s2, evpd 0x0, page code 0x0
        Vendor id                        : EMC
        Product id                       : SYMMETRIX
        Revision                         : 5773
        Serial Number                    : 17!"t000Q
root@pr_ora_db16:/#
root@pr_ora_db16:/# vxconfigd -k
pp_claim_device: Could not get device number for /dev/rdsk/emcpower8
VxVM vxconfigd ERROR V-5-1-8646 Error in claiming /dev/rdsk/emcpower8: No such file or directory
root@pr_ora_db16:/# ls -l /dev/rdsk/emcpower8
lrwxrwxrwx   1 root     root          34 Jan  8 21:31 /dev/rdsk/emcpower8 -> ../../devices/pseudo/emcp@8:wd,raw

Please suggest.

2

Hi Solaris_1977, this certainly looks like the VxVM is having issues claiming the new LUN. But the why behind that isn't clear here unfortunately. We would need to work with you to get some more information to help find the cause - are you able to open a support case with us?

3

Hi,

I think that this could be related to 3 points

1) Compatibiliy betwen the VXVM version and powerpath version
2) The HostLun number used by to map the emc device to Port (in this case d1245) is very high for me
3) Before to this, exist another device named emcpower8 that was linked to another device and the VXVM internal data have reference to another disk, please review the files in /etc/vx/ to search old references to emcpower8

Is very strange for me that the Serial number showed in the vxdmpinq outout was

17!"t000Q

Could you paste the powermt display for your device?
In reference

4

It seems that device paths were messed up, so did following.

And that panicked my production box :frowning: Fortunately it was in cluster so my life was saved. After reboot, new lun was visible in VxVM as well.

5

Solaris_1977

Let me explain new LUNS and the discovery from the VxVM side ....

When the OS discovers a new LUN, there is a new daemon , called ESD (Event Source Daemon) that tries to do the "windows" "plug&play" bit.

Once a new LUN is discovered , ESD then broadcasts to all registered software (like EMCP and VxVM) that there is a new LUN.

Now, here comes the problem.

VxVM and EMCP sees the new LUN at the same time.
EMCP starts creating a new powerdevice for it, and VxVM creates a new disk record for it.

When EMC powerpath created the device, it again sends a message to ESD and ESD then broadcasts this to the other registered software (VxVM).

VxVM now tries to "link" the power device with the disk ...
The reason is that PowerPath already does DMP, and if VxVM also does DMP, you get double the work and double the time for IO.... VxVM does NOT do DMP to powerdevices to eliminate this double work. So, VxVM has to make the "link" between the disk and the power device .....

Now comes the problem.

This all happens so fast, because in the process, VxVM also sends out a ESD broadcast saying that it knows about a new disk and it can do DMP for it (which EMCP picks up and checks and .....)

OK, so how can you solve this ?

The best way is to stop VxVM from "linking" into ESD.
There is a process called "vxesd" (do a "ps" to see)

If you call support, they will tell you to stop VxVM ESD by looking at this link ....
(explains what I did above in more detail and gives the commands to stop it running)

(oops, can not yet post links ... so go to google and search for symanetc and TECH72540)

When the machine rebooted, the device discovery was done by the OS, then PowerPath and then VxVM (correct order), and as such eliminated the problems.

The steps that you followed (scandisks ...) is 100% correct, and should be followed once you have stopped vxesd from running again.

If you do have further questions, please feel free to ask, or if you want me to look at data on your specific machine, let me know