VSI OpenVMS Forum

How to add shadowed system disks in a multiple-member shadow set to the BOOTMGR boot device list (VMS V9.2 + UPD2 x86-64) ?

For Alpha we did this using srm command; for example :

P00>>> set bootdef_dev dga50.1002.0.2.1,dga50.1001.0.2.1,dgb60.1003.0.3.1,dgb60.1004.0.3.1

For Integrity we did this using the OpenVMS Integrity servers boot_options.com utility to add shadowed system disks in a multiple-member shadow set to the EFI boot device list.

I can't find any information in the currently available manuals and various attempts under bootmgr seem to confirm that bootmgr currently supports only one disk boot device configuration.

Any hints will be really appreciated,
/Maurizio

Maurizio,

[quote]
P00>>> set bootdef_dev dga50.1002.0.2.1,dga50.1001.0.2.1,dgb50.1003.0.3.1,dgb50.1004.0.3.1
[/quote]

The above command just adds the 4 possible Fibre Channel pathes to the $1$DGA50 boot disk.

To do what you want, you would also have to add the pathes to the 2nd and 3rd and ... disks of all members of the system disk shadowset.

Volker.

Maurizio,

in theory you could specify the 'boot order' in the UEFI Boot Manager, not the OpenVMS Boot Manager !

You should be able to reach the UEFI Boot Manager by typing BOOTMGR> EXIT and hitting a couple of <ESC>'s quickly.

Enter Setup -> Configure Boot Options -> Change Boot Order

and re-arrange the boot devices in your desired order.

I'm not sure though, if this is a good idea. It will certainly ONLY work, if the first disk from that list completely disappears from the system. Would you want the system to automatically select the next disk to try to boot from ? What happens, if that disk had been removed from (or fallen out of) the system disk shadowset more or less recently ? Would you still try to automatically boot from that disk ?

And note, that in a cluster, the physical first member may still be reachable from other systems and your system would try to boot from the 2nd disk -> bugcheck (boot disk not in shadowset) !

I just tested (on VSI OpenVMS x86-64 V9.2) a manual boot from a disk, that had been a system disk shadowset member and had been manually removed.

You'll get the following messages, but the system will happily boot from that 'outdated' member:

%SYSINIT-I-INCSHAMEM, system shadow set membership inconsistency
%SYSINIT-I-SHASINGMBR, single member system shadow set formed

Not sure, if you want that to happen automatically. I did not try to change the boot order, I just booted using BOOTMGR> BOOT DKA0

Volker.

some implications for future operation of critical systems running OpenVMS x86-64. I think there will be more things to learn about the real world operation of OpenVMS x86-64 systems.

I'm running Shadowed System disk on VMware

Within the VMware UEFI Boot management environment it was easy to add multiple additional boots that loaded the VMS_BOOTMGR from different devices thus allowing BOOTMGR to be run which ever member of the Shadow set was present. I was disable booting from just about all standard devices (parricular;y the NICs) which speeded things up.

it is then a matter of configuring multiple boot options with-in BOOTMGR but I'm not sure BOOTMGR will ripple down the different options should an earlier one fail.

Laurence