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

[Volker Halle]

Marty,

try the VMS_SHOW EFI utility first:

Go to the EFI shell, then select fs2: (a file system on an OpenVMS system disk)

fs2:> \efi\vms\vms_show dev

To change a system parameter during boot, you have to do a converstional boot:

fs2:> \efi\vms\vms_loader.efi -fl 0,1

(assuming your system boots from root SYS0).

SYSBOOT> SHOW DUMPSTYLE ! should be 9
SYSBOOT> SET DUMPSTYLE 11 ! add bit 1
SYSBOOT> C

Then post the console output from the crash.

Volker.

[Volker Halle]

Marty,

based on your Efi> map -r output, the rx4640 can see ONE SAN disk with 4 partitions via 2 HBAs.

Where did you set the 'number' 121, which OpenVMS uses as a boot device ?

Could you also please clarify this:


* I have defined separate UDID's on the SVC Vdisk


separate from what ?

Volker.

[Marty Steffens]

Volker,

I attached the output from the dump. Thanks for your help on that part!
_________________________________________

I'll try to explain the 3 different ID's from the SVC perspective:

UID - this is the 32 byte hex string. For device $1$DGA121 it's 60050768019001BC8000000000000003.

UDID (Unit Device Identifier) - For device $1$DGA121 it is 121. (This is the number that's added on to the device names for OpenVMS).

SCSI ID - This is the SCSI ID of the virtual disk. What I'm seeing here is that one of the SAN disk, or virtual disk, has to have a SCSI ID of zero. Otherwise, VMS will not see any of the SAN disk.

Let me know if you need any further explaination on the ID's. Hope that cleared up some confusion.

Thanks!

Marty

[Volker Halle]

Marty,

on Itanium, R8 typically contains the return or error status (on Alpha it is in R0). An INCONSTATE crash typically leaves the error status in this register, so that you can 'see' it in the crash:

$ exit %xa50
%SYSTEM-W-ITEMNOTFOUND, requested item cannot be returned

Unfortunately, this does not help a lot. You need to raise a support call with either HP or IBM for further assistance.

What did the VMS_SHOW DEV EFI utility report ?

Can you mount the SAN disk (when booted from SCSI) and look at the crash ? At least a CLUE CRASH command would tell which driver crashed the system. Also look at whether the disk is configured correctly.

$ ANAL/CRASH $1$DGA121:
SDA> CLUE CRASH
SDA> SHOW DEV DGA
SDA> EXIT

Volker.

[Volker Halle]

Marty,

I've looked at one of my terminal session capture files from a rx2620 and EVA installation.

I see that NONE of the FC devices shown by EFI> map -r have a LUN value of 0 ! They look like:

Fibre(WWN50001FE15003D5A8,Lun1000000000000)
Fibre(WWN50001FE15003D5A8,Lun2000000000000)
and so on...

Your DGA121 FC disk shows a LUN value of 0. LUN 0 on OpenVMS may be mapped to the CCL LUN (i.e. device $1$GGAx:).

In a DS6000 IBM manual I've read, that the first storage volume assigned to a host is LUN 0. Can you somehow change this LUN value for this Vdisk at the SVC ? Or just present a second Vdisk to the rx4640 and check whether it then becomes LUN 1 at the EFI level and allows you to boot.

Volker.

[Marty Steffens]

Volker,

Our application vendor loaded OpenVMS 8.3 on device $1$DGA122 and received the same BUGCHECK error on a SAN boot. I attached the output from another map -r command. As you can see, the LUN number is different for this device than it is for $1$DGA121 (LUN 0). Just like you were talking about in your previous response.

Can you elaborate a little more on the CCL LUN and and at what level it is configured at? I've see this talked about in a few different threads, but I can't pin point it down to where I should be looking for this.

Thanks!

Marty

[Marty Steffens]

Volker,

I attached the report from the VMS_SHOW DEV EFI command.

Marty

[Uwe Zessin]

>Can you elaborate a little more on the CCL LUN and
> and at what level it is configured at?

CCL (Console Command LUN) was the terminology on HSG60 and HSG80 controllers. On the EVA storage array it is called the SACD (Storage Array Controller Device).

In SCSI terminology, this LUN is not a type 0 (disk), but a type 12(10) device. It is configured on the storage array.

Sometimes it is called the LUN_Z or the 'gatekeeper device'.

Its purpose it to always present a device at LUN address 0, so that SCSI commands like 'REPORT LUNs' work. On some storage arrays like the EVA it is required for in-band management and cannot be disabled.

[Volker Halle]

Marty,

could you try to unpresent DGA121 (the FC device with LUN0) and see if that allows you to boot from DGA122 ?

Volker.

[Marty Steffens]

Volker,

If you mean to unpresent it from the host on the SVC side, then the OS will not see any of the SAN disk because this disk ($1$DGA121) has the SCSI ID of Zero.

Let me know if this is what you are referring to.

Thanks!

Marty

[Marty Steffens]

Volker,

I attached another efi map after removing the mapping of the host to device $1$DGA121 on the SVC. I also had to issue the "reset" efi command to remove LUN0. I still see LUN300000000000. Still received same error, though, when trying to boot from it.

Marty

[The Brit]

Marty,
Could you also show the output from the Boot Manager Screen.

Dave.

[Volker Halle]

Marty,

you'd either have to involve IBM or HP support to find out what kind of configuration problem causes the INCONSTATE crash. Only HP OpenVMS Engineering (or the HP support center, if this problem is already documented internally) will know, what causes this crash to happen.

Volker.

[Marty Steffens]

Volker,

A developer from SVC Support is able to recreate the BUGCHECK problem at their lab in Tucson, but currently have no resolution to the problem. I will update this thread when the resolution is found. Thanks again for all your help.

Marty

[David Huber_1]

any update on SVC functioning with OpenVMS....we are looking to transition some 7.3-2 systems to SVC based storage...

Please advise
thanks
david