Setting up a volshad'ed FC boot disk

[Martin Vorlaender]

Hi!

I have a configuration with a DS25 (actually, a three-node Alpha cluster with two systems on the SAN and a quorum machine) connected to two EVAs in different locations.

All disks have been set up as shadow sets with one shadow member in each EVA, including the system disk.

I assume it should be possible with wwidmgr to enter all paths to both members of the system disk into bootdef_dev to have full redundancy.

What I see, however, is that when I -quickset the second UUID, the first one configured vanishes from the list of "disks available after the next init", and isn't offered for entry into bootdef_dev.

The SRM variables wwid* hold information on both disks - I just cant't see them using show device.

Please advise.

Thanks,
Martin

[Kris Clippeleyr]

Martin,
Having no experience with EVA (only with MSA), I can only tell you that the following has worked for me.
At the console prompt of an Alpha:

P00SG1A>>> wwidmgr -clear wwid0
P00SG1A>>> wwidmgr -clear wwid1
P00SG1A>>> wwidmgr -clear wwid2
P00SG1A>>> wwidmgr -clear wwid3
P00SG1A>>> wwidmgr -quickset -udid 100
P00SG1A>>> wwidmgr -quickset -udid 101
P00SG1A>>> wwidmgr -quickset -udid 104

Disk assignment and reachability after next initialization:


6006-0b00-0081-e230-f3e9-6526-2de1-001c
via adapter: via fc nport: connected:
dga100.1001.0.1.1 pga0.0.0.1.1 5006-0b00-0081-e239 No
dgb100.1002.0.2.1 pgb0.0.0.2.1 5006-0b00-0081-e231 Yes

6006-0b00-0081-e230-ce99-383d-556e-001d
via adapter: via fc nport: connected:
dga101.1001.0.1.1 pga0.0.0.1.1 5006-0b00-0081-e239 No
dgb101.1002.0.2.1 pgb0.0.0.2.1 5006-0b00-0081-e231 Yes

6006-0b00-0081-e230-2d6b-a265-06f5-0020
via adapter: via fc nport: connected:
dga104.1001.0.1.1 pga0.0.0.1.1 5006-0b00-0081-e239 No
dgb104.1002.0.2.1 pgb0.0.0.2.1 5006-0b00-0081-e231 Yes
P00SG1A>>>
P00SG1A>>> set bootdef_dev dga100,dgb100,dga101,dgb101
P00SG1A>>> set ffauto on
P00SG1A>>> init
Initializing...
P00SG1A>>> b dgb100
(boot dgb100.1002.0.2.1 -flags 0)

I think you might want to set that FFAUTO console variable.

Regards,
Kris (aka Qkcl)

[Uwe Zessin · Accepted solution]

Hi Martin, long time not seen...

Old SRM consoles only provide support for 4 boot paths. The N0..N3 variables which contain the EVA host port WWPNs are fully used up by a single 4-port EVA.

As far as I can tell, there is newer firmware for at least some models available, maybe for the DS25, too.

If not, you might be able to tweak N% to hit 4 unique controller ports. Sorry, I don't have the infrastructure right now to test it. Have fun!

[Uwe Zessin]

> there is newer firmware

What I meant is that this firmware allows to store more target ports by using more N% variables.

[Martin Vorlaender]

Hi Uwe,

good to still see you lurking (even if it's more on the storage than on the VMS side ;-).

You seem to have quite a point there, tough the firmware is current on the DS20E (not DS25 - sorry for the mis-information).

I just looked into one of our ES40s, and it does have 8 N% variables. I can't check the DS20E at the moment, but it could well be that (even with the current 7.2 FW) it only stores 4 port pathing infos at most.

I guess I'll have to take a deep look into the wwidmgr manual, and see what I can up with.

cu,
Martin

[Peter Zeiszler]

Sometimes you have to do an init after the clear statement.

On one of our older systems we actually only get 1 path per device showing up. So we end up using n0,n1 for one disk and n2,n4 for the other disk. (I can send an example if you are interested)

If you have your dumpfile off the system disk you also want to have that device setup with wwidmgr also.

I personally never use the quickset but manually set the unit numbers and information for each device assigned.

wwidmgr -set wwid -item 3 -unit 389
wwidmgr -set port -node 3 -item 3
wwidmgr -show wwid -item 3 -full

So that would setup N3 for the device item number 3 and I set the unit number as 389. I based the unit number off the CU:LDEV and it should automatically assign those unit numbers but I have ran into issues before on that.

When you are done definitely show the environment and the fabric. Capture that information in case you have issues in the future or if you are setting up another system using those same disks. You can then compare paths for verification of disks.

[Bill Hall]

Martin,

I think Peter is on the right track, you need to review the WWIDMGR documentation and manually configure the ports and wwids/units. IIRC, quickset has a limitation of only working for LUNS from the same array.

Bill

[Peter Zeiszler]

I forgot to add - Make sure that you don't have the same CU:LDEV or unit numbers being presented from both arrays.

So if array1 is giving you unit 50 or CU:LDEV 0:32 that the array2 isn't giving the same unit or CU:LDEV. That can really confuse the systems.

If the array has a starting value like 0 then it automatically assigns the other devices, then make sure the array2 starting value is higher than the amount of disks the array1 will present. We had that with EMC. Had to make array2 start with a base value of 4000.

On our XP1024s we just make sure via maps that we don't present same devices via their CU:LDEV.

[Uwe Zessin]

Good point. The EVA is very flexible, because you have complete control on the unit number. Usually, I use values like 100..199 for the first box, 200..299 for the second box. That makes up a nice "SHOW DEVICE D" display.

0, however is not a good idea, because it means 'don't assign a number'. It's been some time I've tried it, but I think the WWIDMGR shows [-1] in the UDID column - in that case OpenVMS does not recognize the disk.

[Martin Vorlaender]

Thanks for all the good advice.

I will check the DS20E SRM to verify it can only hold 4 N% variables (I wonder which documentation has such information). The wwidmgr manual has a section about manually selecting paths.

The LUNs/Unit IDs in the EVA have been set up to be non-0, single-digit in one EVA, and offset by 10 in the other one.

The system dumps to the system disk; dump_dev has been set up accordingly.