Satelite with FC HBAs

[Adrian Gehrig]

Is there an easy way to configure an existing Alpha OpenVMS 7.2-1 Satellite connected via LAN and bootet with MOP to a Cluster Node with FC HBAs which are connected to our SAN.

So far I configured the SAN and I can see the disks on the SRM Console. When I try to boot via the DGA Device the system crashes immediately after "jumping to bootstrap" It says something like SYS10 doesn't exist and about a wrong HWRPB - which is wrong! The existing SYS10 was the system the satellite had via network boot. I didn't find informations in our documentations about the differences of a system that is set up with direct attached disks and a satellite.

The DS15 AlphaServer boots fine over the network - but unfortunately not direct from the disks.

Thanks for your help!

[Volker Halle]

Adrian,

you did run >>> WWIDMGR -quickset -udid n (where n is the unit id of your SAN system disk) ?

Then you are booting: >>> B -fl 10,0 DGAn

This should be straightforward. The message about the wrong HWRPB is probably only a secondary effect of the failed boot. Could you provide the full boot command and error message ?

Volker.

[Adrian Gehrig]

Hi Volker

I've been in the office, when writing the question. Now I have recorded some more infos that you can see in the attached log...

I am not really sure how to boot from the dga device. What is the popper way b $1$dga1 or b dga1.1002.x.x?

[Volker Halle · Accepted solution]

Adrian,

thanks for providing this much more detailled information. This allows me to answer and solve all of your questions/problems in one go:


As you have 2 FC adapter connected to 2 different fabrics, your devices on the HSG80s are available via 4 pathes.

You can only boot from a 'connected' path, so you should specify all 4 possible device pathes in BOOTDEF_DEV (and DUMP_DEV), i.e.

>>> set bootdef_dev dga1.1001,dga1.1002,dgb1.1003, dgb1.1004

and the same for DUMP_DEV.

To boot, you need to specify a 'valid' device name, as seen by the SRM console:

>>>b $1$dga1 -fl 10,20000
(boot dka0.0.0.8.0 -flags 10,20000)
...
%APB-I-SYSROOT, System root is [SYS10.]
%APB-F-BADSYSROOT, System root [SYS10.] does not exist, check bootflags

'$1$dga1' is an invalid console device name, so the boot defaults to using DKA0:, which obviously does not seem to include a [SYS10] directory.

You correct boot runs into another problem:

>>> b dga1.1002.0.9.2 -fl 10,20000
...
%INIT_IO_DB-F-CFG_DEV_NOT_FOUND, A device on the boot line, or in BOOT_DEV, cannot be found in the config tables.
-Console pathname SCSI3 2 9 0 2 0 0 0 @wwid0, ID = FA0010DF.FA0010DF
-Ignoring the device, and not loading boot driver
%IOC$DISC_BOOT-I-DISC_PBD, Disconnecting from primary boot device
...
leading to an INVEXCEPTN crash.

The problem here is, that the version/patch level of your OpenVMS V7.3-1 does not include support for the Fibre Channel adapter FCA-2684 installed in your system.

This is from an OpenVMS Alpha V8.2 system:

AXPVMS $ sea sys$system:sys$config.dat FA0010DF/wind=(5,5)

device = "3R-A513*-AA (Emulex LP10000)"
name = FG
driver = SYS$FGEDRIVER
adapter = PCI
id = 0xFA0010DF
boot_class = PG
boot_flags = HW_CTRL_LTR, UNIT_0
flags = FIBRE, PORT, BOOT
end_device

So this is an LP10000 FC adapter, support for this adapter has been added in the VMS731_FIBRE_SCSI-V0600. Please consider to install the most recent patches for V7.3-1 and everything will work as expected.

Volker.

[Robert Brooks_1]

V7.2-1 is quite ancient for fibre channel and multipath. Please upgrade to something more modern; there have been a fair amount of bug fixes since the last patch kit for V7.2-1 with respect to the storage subsystem.

If you cannot upgrade to at least V7.3-1, please make sure that MPDEV_REMOTE = 0 (0 is the default for V7.2-1, so unless something weird has happened, you should be OK.)

-- Rob

[Volker Halle]

Robert,


V7.2-1 is quite ancient for fibre channel and multipath


V7.2-1 is a typo in the initial posting. A DS15 wouldn't even boot with V7.2-1 (needs at least V7.3-1 + patches). This DS15 system is running with V7.3-1 (as can be seen from the console log file posted in one of the previous replies).

LP10000 support showed up with VMS731_FIBRE_SCSI-V0600 or V7.3-2.

Volker.

[John Gillings]

Adrian,

There's a terminology issue here. A Satellite node boots via a host node.

Any node that boots directly from a disk isn't a satellite (not sure if there's an official name for it). Normally roots higher than F (hex) are used by satellites, and I'm not certain if "10" is valid as a root specified in the >>> BOOT command.

Simple test, try RENAMEing or creating an alias directory for your SYS10 root as a single digit (SYS4, SYS5, SYSA, SYSB etc...) and try booting from there.

[Volker Halle]

John,

as far as I understand Adrians configuration, this node is/was a satellite node (booting via LAN) and - after adding a FC adapter - is now being re-configured to boot directly from it's FC system disk.

There is no problem booting an OpenVMS system directly from a [SYS10.] root on a disk. As an example, have a look at an OpenVMS Alpha Operating System CD and you'll see all possible 2-digit system root directories present ([SYS0] up to [SYSFF]).

Volker.

[Adrian Gehrig]

It finally works! After the SCSI patch update I was able to boot via HBAs.

In the end we updated the system to OpenVMS 7.3-2 since there is no official support from HP to older versions than 7.3-2. There the SCSI_FC patch was needed to boot with those HBAs. I was surprised that there where no other changes neccessary for that configuration change - I love VMS!