GETDVI on VMS for multipath device - is path available?

[Russell Grossman]

I have a need to determine whether a path to a multipath device on VMS is available or not (is there a physical path problem).

We have a VMS system that had several LUNs served to it by the backend eva, but, when we take down the eva or un-cable the paths I can't figure out how to tell from the operating system. You can tell if a mounted volume went away and that all paths are down but not if a single path or multiple paths are down as long as the volume is accessible.

I tried GETDVI PATH_AVAILABLE and PATH_NOT_RESPONDING but they never change states (PATH_AVAILABLE is always TRUE and PATH_NOT_RESPONDING is always FALSE) like the operating system never tests the paths to see if they are still alive at all once they have been configured. I also tried looking for anything in the device data structures in SDA and can't figure out anything.

Does anyone have a recommendation on how to test a path to see if it is still available and working?

I am willing to go through any number of steps to determine is a path is available or now.

Thanks,

Russ

[Peter Weaver_1]

I don't have any multi-path devices anymore so I cannot test this myself, but what does F$GETDVI(device,"PATH_POLL_ENABLED") tell you on these devices? Does PATH_AVAILABLE and PATH_NOT_RESPONDING change states if you do a SET DEVICE/POLL first?

[Russell Grossman]

Good idea but doesn't change anything... the following path was not available and Vms does not seem to record that fact anywhere...

Vms006$ set device /path=FGB0.5001-4380-2A56-F28A/poll $1$dga500
Vms006$ write sys$output f$getdvi("$1$dga500","PATH_POLL_ENABLED","FGB0.5001-438
0-2A56-F28A")
TRUE
Vms006$ write sys$output f$getdvi("$1$dga500","PATH_AVAILABLE","FGB0.5001-4380-2
A56-F28A")
TRUE
Vms006$ write sys$output f$getdvi("$1$dga500","PATH_NOT_RESPONDING","FGB0.5001-4
380-2A56-F28A")
FALSE

[Peter Weaver_1]

Can you post the result of SHOW DEVICE/MULTI $5$DKA101:? I am curious to see what the "Paths Avl/Tot" shows.

BTW: I did find a customer that has multipath devices, but they have V7.2-1 and that version did not have full multipath support.

[Robert Brooks_1]

This is a bit more complex than it appears.

As long as ANY LUN on a path responds, the path is considered to be good. The multipath poller does probe each path once a minute (or every 30 seconds if a path is bad). However, this is not a device-specific check, and I admit that displaying the status on a per-device basis (as in $ SHOW DEVICE /FULL) is a bit confusing.

What problem are you trying to solve? If a path goes bad, multipath will find a working path, if one exists. Preemptively trying to do multipath's job is likely to be met with confusion, as you are seeing.

-- Rob (who worked on multipath, and did all the multipath-related work to $GETDVI).

[Russell Grossman]

There are 9 paths and one is MSCP. So, there are 8 paths through the fc hba and they all show active and available except for the fact the backend is down for maintenance.

Vms006$ show device/multi $1$dga500
Device Device Error Current
Name Status Count Paths path
$1$DGA500: (VMS006) Online 0 9/ 9 FGB0.5001-4380-2A56-F288

The san will be back up Friday and I was going to see what I could find then. Thanks for your help!

[Russell Grossman]

Hi Rob... I am actually a contractor working on the EVA CAST (common automation and system test) test tool adding support for the VMS operating system. CAST users do things like perturb (pull cables etc...) the eva environment and then see that the os sees, what events are logged, and that everything still works among other things like load testing. With vms sysman io auto, we can rescan the luns and see when new luns become available. But, when things become unavailable I can't figure out a way to know this in Vms. I can know when no paths are available (e.g. can't see the volume) but if there is a hardware problem in some but not all of the paths, I'm not sure Vms would ever know. Would seem like a reasonable thing that SET DEVICE/PATH/POLL would test the path (and record a bit somewhere) but I think that is all left up to mount verify in Vms.

[Russell Grossman]

If I could tell by looking at the fc hba which paths were up and which were not, this would be good enough.

[Robert Brooks_1]

Hi Rob... I am actually a contractor working on the EVA CAST (common automation and system test) test tool adding support for the VMS operating system.

--

I'm not familiar with CAST; are you a contractor for HP? If so, contact me at
rab (at) hp dot com

-- Rob