Does OpenVMS support Huawei OceanStor Storage?

[albert000]

We tried to integrate OpenVMS with a new storage from huawei,  but were unsuccessful.

OpenVMS and the storage both support SCSI protocol, but can't play well togather.

So , I think this integration need the joint development that HPE provide special SCSI Commands, and then storage vendor does the corresponding development, right?

How to start the integration between Huawei Storage and HP OpenVMS?

[Steven Schweda]

> We tried to integrate OpenVMS with a new storage from huawei, but
> were unsuccessful.

   Not a very detailed description of any of the hardware or software
involved.  Not a very detailed description of what you did, or what
happened when you did it.

> How to start the integration between Huawei Storage and HP OpenVMS?

   Talk to Huawei and/or HP[E]?

[Hoff]

If you're using some particular Huawei widget, it'd be very helpful if you identified the specific Huawei model involved, and provided information on the OpenVMS server model, OpenVMS version and patch level, and the particular hardware storage I/O path — controller, cabling, etc — involved in this configuration.

This Huawei OceanStor configuration very likely isn't supported by HPE, VSI or Huawei, and you almost certainly already know that, too  (Why unsupported?  You'd have doc for it, and it'd probably connect and work, if the configuration was considered supported by one or more of the vendors involved.)

If you're working for Huawei or a Huawei reseller, contact the folks at VSI directly.

HPE is unlikely to be interested given they're exiting the OpenVMS business in the relatively near future, but you could certainly ask them and see if they're interested in helping qualify this configuration.

If you're rolling your own Fibre Channel Storage Area Networkl (FC SAN) support here — more than a few of the OceanStor boxes list Fibre Channel, among other options — you'll minimally need to understand the particular interconnect used here — the only path that appears to have some chance of working with the particular Huawei widget is probably Fibre Channel (based on a quick look at the specs for one of the many models that Huawei sells), so you'll need to zone and configure the controllers appropriately, and figure out how to set the device unit IDs — if that logical unit identifier mechanism is even present and permissible on the particular FC SAN controller in use here — that OpenVMS expects.

If the particular Huawei OceanStor device presents one or more generic SCSI storage devices, that should work with most any recent OpenVMS release, but there can be many different sorts of presentations, SCSI bus configurations, and SCSI termination and related requirements. 

Related Fibre Channel info here and here.

[albert000]

Thanks for your replay.

I describe my question in detail as follows:

When we connect OpenVMS to HUAWEI storage system, we find the FC links are online. But when we map LUNs to the OpenVMS host, the OpenVMS host cannot find the mapped LUNs.
The configuration is as follows:
hardware: HP rx2800 i2
VMS version: OpenVMS 8.4
Storage system: HUAWEI OceanStor 5500 V3

We capture the signal between OpenVMS and HUAWEI storage system, and find that OpenVMS send a special SCSI command(Opcode：0xEC).

The specification of this command can't be found in SCSI protocol document, therefore we don't know what content we should send back for this SCSI command and what conditions the command will be used .

Could you please provide the specification of this command to us?

[abrsvc]

One thing to check is the OS_ID of the mapped LUNs.  It MUST be NON-zero for OpenVMS to see the LUN.  

Check that and update this with the results.

Please note that if this resolves the visibility issue, that this is still an unsupported configuration.

Dan

[albert000]

Dear Dan：

    Thanks very much for your reply.

     We have tested the cases: mapping with NON-zero OS_ID LUN and with zero OS_ID LUN. However the problem are the same:OpenVMS can't find the mapped LUN.

    One good new HUAWEI engineers tell me is that when they response the 0xEC scsi command the same  as other storage vendor reponse, then OpenVMS can find the LUNs.

     But we still don't know the function of 0xEC scsi command,  whether the message we reponse is right or not, whether it has other problems or not.

     Therefore, could you please provide us the specification of this command, or could you tell us what we should do to support this command?

     Looking forwards to your reply.

Tong

[Hoff]

EC is a vendor-specific command, with no defined format or purpose, and likely varies both by vendor and quite possibly also even across one vendor's devices.

Some controllers require the OS_ID be input in hex, some take it in decimal.

Get VSI and/or HPE support involved here, and get them talking directly with Huawei.

[Jur van der Burg]

VMS needs a so called 'identifier' for the fibrechannel storage which is retrieved from the storage controller with either the 0xEC command (rd_devid) or 0xA3 (management_in).  It expects a certain formatted number between 1 and 32767. If VMS cannot retrieve it you cannot use the storage. So all controllers that VMS can use MUST support either of these scsi commands, if the Huawei cannot handle that you're dead in the water.

(there are possibilities to use such a controller in an emulator where you can do all kind of dirty tricks, but since you're talking about Itanium it does not apply here).

Jur.

[albert000]

Dear Jur:

     Thanks very much for your reply.

     We have compared the interactive information between OpenVMS and storage system from other vendors.  And we found other vendors' storage also not support 0xA3 command, but they can support 0xEC command.

     We want HUAWEI storage to support 0xEC command, the same as other vendors do. But we can't get the specification of this command.

     Could you please provide us the specification of this command, or could you tell us what we should do to support this command ?

     looking forware to your reply.

[Hoff]

Contact VSI, the folks that are creating new OpenVMS releases and maintaining new releases going forward, and ask them for assistance with this — they'll know the details of the SCSI commands they're using with OpenVMS now, as well as what HPE is presently using.   This because HPE isn't likely enhancing OpenVMS and is planning on getting out of the OpenVMS business, so VSI is likely the better contact here.  Getting in contact with VSI may also get you some information on changes that VSI may be planning in this area as part of their x86-64 OpenVMS port, or related new work.