Problem with OpenVMS SAN Boot from IBM SVC

[Marty Steffens]

Hello everyone,

We're attempting to boot our OpenVMS partition from our SAN and we keep receiving a BUGCHECK code 19:INCONSTATE error msg. Please refer to the attached print screen for more details on the error message.

Here's our environment:
* OpenVMS 8.2.1
* HP Integrity rx4640 Server I64
* HP A6826A FC HBA (Qlogic ISP2312) 2 of these.
* HBA Firmware Driver-1.49 Firmware-3.03.154
* IBM SAN32M Switch (McData 4700)
* IBM SVC running at 4.1.1.3 code level
* IBM 2105-800 Shark on back end of SVC.

Other Information:
* I have defined separate UDID's on the SVC Vdisk per OpenVMS documentation. The Vdisk for the System Boot Disk has a SCSI ID of Zero.
* The "OS Mode" boot option on the HBA firmware is set to HP-UX/OpenVms.
* I have one path defined in the SAN Fabric for each HBA.

Please let me know if you need any further information from me. Thanks in advance for any information!

Marty

[Tom O'Toole]

I don't think you can use os_id of zero. The first thing you should try is a non-zero unit.
let us know...

[Jan van den Ende]

Marty,

Tom wrote

>>>
I don't think you can use os_id of zero. The first thing you should try is a non-zero unit.
<<<

I can even more definite: that _IS_ the issue.

Change all devices that are intended to be seen by VMS to non-zero IDs.

I do not exclude other potential issues, but THIS one definitely is prohibitive.

hth

Proost.

Have one on me.

jpe

[Marty Steffens]

I made the changes on the SVC so that the vdisk have a SCSI ID of 1 thru 6. Now I don't see any of the LUN's from the SAN after a reboot. When you mention the OS_id, are you referring to the SCSI ID on the SVC that I'm talking about or are you referring to something else?

I did run the IO SCSI_PATH_VERIFY and IO AUTOCONFIG commands, but still can't see the drives.

Thanks!

Marty

[Jan van den Ende]

Marty,

>>>
I did run the IO SCSI_PATH_VERIFY and IO AUTOCONFIG commands
<<<

Does this imply you now booted without a crash?

Then that would imply you see at least the system disk... Please attach the output of
$ SHOW DEVICE SYS$SYSDEVICE
as an ASCII file with .TXT extension.

If my assumption is false, then how did you get to where you ran SYSGEN IO AUTO ?

Proost.

Have one on me.

jpe

[Marty Steffens]

Sorry about that. I forgot to mention that I rebooted from the Internal Drive just to see if I could see the SAN disk before I tried to boot from the SAN. I attached the command you asked for.

Thanks!

Marty

[Volker Halle]

Marty,

according to the console output, you have been booting from $1$DGA121, when you were seeing the INCONSTATE crash. The EFI console did find the boot path and the dump also worked, so a path to that disk did exist. OpenVMS needs to use the SAME UNIT IDENTIFIER for that device as the console.

If you would enable full console output during the dump (SET DUMPSTYLE bit 1), you should see a failure status in R8. This should tell you what's wrong.

What does the following command tell you about the FC disks:

EFI shell> map -r

Volker.

[Uwe Zessin]

> When you mention the OS_id, are you referring to the SCSI ID on the SVC that I'm talking about or are you referring to something else?

Good Question! Unfortunately, the names are all but clear.

My guess it that when you talk about a "SCSI ID", it is really the "LUN address" (sometimes also called "LUN ID", sigh) for mapping a virtual disk. OpenVMS _needs_ a device at LUN address 0, because - as far as I know - it uses SCSI-3 style "REPORT LUNS" inquiries to find FC LUNs.

The "UDID" or "OS Unit ID" or "Unit Identifier" (or what else... - it is 121 in the attachement), which is used to assign a unit number within the SRM console or OpenVMS (DGA121:) lives within a vendor-specific page. Not all arrays can provide this feature. You say you have assigned 6 UDIDs, so apparently the SVC does have that feature.

Can't help with the debugging (Volker is the right person ;-), but maybe I could clear up some confusion.

[Tom O'Toole]

A LUN is a per-host specific quantity, and it can be different for each host a volume is presented to. But since with VMS several systems may be accessing the same volume concurrently, it needs to know, hey, this is the same volume. So the UDID/os_unit_id provides the "volume specific lun" that vms requires.

[Marty Steffens]

Volker,

I attached the map -r command. I see all the FC devices are LUN0. I had to changed the SCSI ID back to zero on the SVC for device ($1$DGA121) so that I could reproduce the error. I'm "very" OpenVMS challenged so I'm having troubles changing the DUMPSTYLE parameter to 1. Can I do this through the EFI shell, or do I have to have the OS booted to changed this option? Plese reply back with the proper commands to do this.

Regards,

Marty