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