volume shadow on msa1000

[Olaf Hamann]

We have a redundant cluster configuration with
two msa1000 (FW 3.36) and two VMS 7.3-1 Hosts.
Problem: MSA1000 only works in active/standby mode, so after rebooting VMS some msa1000 units
appear to VMS over the standby path and could
not be mounted. We have to make a "set device..
/switch/path=pga0" to get access to the disk.
Question: Is it sufficient to make a "set device .../switch/path.." in the system startup file before the "mount/system $1$dga1:
/shadow=$1$dga10" or will the path problem break my shadow set on every reboot ???

[Åge Rønning]

OpenVMS should automaticly switch to the correct path if correctly configured. I've been rebooting a MSA1000 based cluster many times the last months without seeing this problem.

Are you sure the MSA1000 configuration is correct. ACL added to all units? Correct profile name topology?

You may want to make a mount prosedure that checks availability of all volumes before mounting. Also have a look at MOUNT/POLICY=REQUIRE_MEMBERS to prevent mounting shadowset without all members available.

[Olaf Hamann]

reply to Age:
The MSA1000 Systems are redundant (two FC Ports), profile is set to openvms, but no ACL, because all hosts should have access to all ports of the MSA´s (standby port in the in case of failover)
If we restrict the access to the active port
with ACL, then the failover will not work.

[Åge Rønning]

Difficult to say without more specific information about the config and the setup, But I assume you have installed the latest FIBRE_SCSI and MSA1000 patch kit?

Each Unit and controller assigned a unique ID?

ACL should be OK as long as you add all connections:

show acl

ACL is enabled:
Connection WWPN Units
alpha1_fga0 10000000-C9334CF8 1, 2
alpha1_fgb0 10000000-C9334D52 1, 2
alpha2_fga0 10000000-C9334E82 1, 2
alpha2_fgb0 10000000-C9335306 1, 2
Inaccessible Units: 3, 4, 5

MSA1000_1>> add acl connection=alpha1_fga0 unit=all
Allowing 10000000-C9334CF8 access to unit 1 2 3 4 5.

MSA1000_1>> add acl connection=alpha1_fga0 unit=all
Allowing 10000000-C9334D52 access to unit 1 2 3 4 5.

MSA1000_1>> add acl connection=alpha1_fgb0 unit=all
Allowing 10000000-C9335306 access to unit 1 2 3 4 5.

MSA1000_1>> add acl connection=alpha2_fgb0 unit=all
Allowing 10000000-C9334E82 access to unit 1 2 3 4 5.

MSA1000_1>> show acl

ACL is enabled:
Connection WWPN Units
alpha1_fga0 10000000-C9334CF8 1, 2, 3, 4, 5
alpha1_fgb0 10000000-C9334D52 1, 2, 3, 4, 5
alpha2_fga0 10000000-C9334E82 1, 2, 3, 4, 5
alpha2_fgb0 10000000-C9335306 1, 2, 3, 4, 5
Inaccessible Units: None

[Mike Naime]

THere is also an HBA firmware update that is required to properly use the MSA1000 with VMS. This is part of the reason why VMS certification was held up so long.

Do you have the latest HBA firmware in your Alphaserver?
Do you have the VMS731_MSA1000 patch?

Did you upgrade the firmware in the MSA1000 itself to support VMS?

I have some MSA's that where shipped in Jan 03' and I need to perform all of these steps before I can properly use them.


PGA0 should be the default path on the Alphaservers. Are you sure that you have your primary path on your servers connected to the same fabric as the primary port on the MSA1000? Or do you have these swapped?

VMS really should not care which is active. it should find it without your intervention.