Symptom Many trespasses and trespass storms are observed.
Cause OpenVMS has native multipathing. At boot time it randomly selects which path to use to initiate I/O and mount the volume. The chosen path may not be the primary (owning) path.
Fix In the OpenVMS boot script insert the following command for each volume just before the volume is to be mounted:
Where the PATH is the path to the default owning SP. Place this as close to the mount command as possible so that OpenVMS does not select a path on its own. This must be done for every volume on every node. And every node must be identical. That is, although the path names may be different because there are different HBAs, every node must be set so that for each volume they all access the volume via the same SP. This will eliminate trespass storms when a node is booted.
Note OpenVMS has no knowledge of an owning SP.
Note Some devices may be owned by SP A and some device may be owned by SP B for load balancing purposes. See the Host Connectivity guide for guidance for load balancing.
Note If a path fails on one node some time later (after everything has been running properly) that node will use the "mount verify" sequence. The timeout for a path to be deemed failed is 20 seconds. The node will randomly select another path which may or may not be a path to the default owning SP. At this point devices may trespass to the non-owning SP. Since other nodes will continue to access those LUNs via the owning SP, they will continue to trespass each time an I/O is issued. This may lead to trespass storms unless this failure is detected quickly and the node brought down or the path fixed quickly and another set device/switch/path= command is issued to force I/O via the owning SP.