PARSEC Technical Information

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
OpenVMS does, in fact, support SAN technology and has for a very long time. Digital, Compaq, and HP all made their own storage and sold it for interop with VMS. This was the case from the very beginning, but SAN technology didn't hit the scene really until the 1990's. 

=== OpenVMS SAN Limitations ===

VMS does not work with most SANs. The reason being is that there is a SCSI field in the Fiber Channel header which contains a bit of data most folks call either a "UDID" or "OSID". This is a number globally unique to the LUN assigned by the SAN controller. Most SANs simply do not provide this field. So, most SANs do not work with OpenVMS. Another common problem is that OpenVMS doesn't support the newest revision of the SCSI command set which most people call SPC-4 or SAM-4. Instead, only up to SPC-3 is supported. If your SAN tells VMS that it'll do SPC-4 VMS I'm told VMS will ignore the entire bus. 

=== What is the UDID? ===

We are pretty sure it's the first four bytes of a field called SCSI identification ID (by some, many other inconsistent names have been witnessed, too). The field data comes from packed binary data returned SCSI INQUIRY command (CDB) return value. It's a field that can be returned from the utility [[http://manpages.ubuntu.com/manpages/impish/en/man8/sg_ident.8.html|sg_ident]] which is part of SG3 Utils. That's a package originally developed on Solaris, but ported to FreeBSD (of course, their SCSI implementation is the only one on par with Solaris), Tru64, and even Linux.  It can also be set with the __sg_ident__ tool but it's still unclear if any types of software based SAN technology actually works with VMS. There are some rumors it does with some hacking on the server side. 

On the VMS side, the UDID has hundreds of references in device driver and SCSI code. It's also present on some ATA devices and other unexpected places. I can see from the code that any value greater than 9999 will result in OpenVMS rejecting the LUN for use in as a shared MSCP device in a VMS cluster. I can also see that  the code will not accept a value greater than 32767 in decimal. So it would appear that the 4-bytes are not all usable for VMS, perhaps just the first two really matter.

=== OpenVMS Supported SANs ===

Here are the ones we know current definitely support OpenVMS. 

  - HP MSA 1000 SANs (very old and uses SCSI SCA disks which are getting rare)
  - HP MSA 2000 SANs (but newer units only support OpenVMS 8.4)
  - HP EVA SANs (certainly not recommended as these are pretty awful SANs)
  - NetApp SANs based on OnTap version 7. (we are unsure about Cluster-mode/V8)
  - 3PAR SANs appear to work. Support built into the SAN OS/firmware and seems to be left alone.
  - Some Hitachi SANs appear to work, but it's unclear which ones. USP-V and HUS versions seem mostly solid
  - Pure Storage seems similar to 3PAR having the UDID/OSID pretty well baked in, unclear if this is still the case. 
  - Older EMC Symmetrix SANs (2000 and 3000) seem to work. VMAX is is also known to work. 


These are SANs which seem like they might work, but don't have clear support.

  - Solaris and Illumos COMSTAR based SANs
  - SCST and ESOS based SANs (we tested this extensively. Definitely doesn't work in default configuration)
  - Linux LIO (focused much more on iSCSI which pollutes all the documentation)
  - FreeBSD's CAM Table Layer (docs here are almost non-existent. Unclear if it's even possible)

Here are a few scenarios we definitely know do not work. Please email vms at parsec dot com if you think either of these lists need an update or contain an error. 

  - HP MSA 2040 or 2050 with OpenVMS 8.3 or earlier
  - SGI InfiniteStorage SANs
  - Most HP XP SANs
  - VMware based vSAN
  - Promise SANs
  - Compellent Storage SANs

=== Finding Out if Your SAN Works ===

Look at the output from scanning your system. If you see "Unable to get target data" after finding a LUN, then you are looking at either an unsupported SAN or a SAN which hasn't yet had it's "port personality" set to OpenVMS and/or missing UDID fields at the per-LUN view. Some SANs allow you to set each LUN's UDID separately, and others automatically just number up from "1". Remember that OpenVMS does not like SCSI IDs or FC bus IDs which are set to zero (0). The reason here is that they tend to assign the bus ID 0 to the controller. This is definitely the case with the MSA 1000. The back-and-forth signaling that items like "msautil" are using is SCSI itself. It's just encapsulating the commands inside of special SCSI command data blocks (CDBs).  

In this example, you can see that some LUNs are found on an MSA1000. However, incompatible LUNs are also shown. In this case, there are five broken LUNs and three working ones. Be aware that you won't get this output if you are using 'mc' to rescan the fiber bus. So, that's not recommended for troubleshooting.

<code>
CLASS8$ run sys$etc:fibre_scan

**************************************************************************
**************************************************************************
**                                                                      **
**    Scanning port FGA for all Fibre Channel devices (display only)    **
**                                                                      **
**************************************************************************
**************************************************************************

Probing Target 1 ==========================================================

Target = 1. LUN = 0.
----------------------
Standard Inquiry failed, status = 84
Unable to get target data at target 1 LUN 0, status = 84

Probing Target 2 ==========================================================

Target = 2. LUN = 0.
----------------------
Standard Inquiry failed, status = 84
Unable to get target data at target 2 LUN 0, status = 84

Probing Target 3 ==========================================================

Target = 3. LUN = 0.
----------------------
Standard Inquiry failed, status = 84
Unable to get target data at target 3 LUN 0, status = 84

Probing Target 4 ==========================================================

Target = 4. LUN = 0.
----------------------
Standard Inquiry failed, status = 84
Unable to get target data at target 4 LUN 0, status = 84

Probing Target 5 ==========================================================

Port WWID:   5008-05F3-0012-00F1
Node WWID:   5008-05F3-0012-00F0

Target = 5. LUN = 0.
----------------------
Devname:     $1$GGA1:
WWID:        02000008:5008-05F3-0012-00F0

Reported LUN count = 3. at target 5.
Target = 5. LUN = 11.
----------------------
Devname:     $1$DGA200:
Vendor ID:   COMPAQ  
Product ID:  MSA1000 VOLUME  
Devtype:     0 (Disk)
Rev Level:   4.32
WWID:        01000010:6008-05F3-0012-00F0-0000-0000-0375-0041

Target = 5. LUN = 12.
----------------------
Devname:     $1$DGA201:
Vendor ID:   COMPAQ  
Product ID:  MSA1000 VOLUME  
Devtype:     0 (Disk)
Rev Level:   4.32
WWID:        01000010:6008-05F3-0012-00F0-0000-0000-44C7-0042

Probing Target 6 ==========================================================

Target = 6. LUN = 0.
----------------------
Standard Inquiry failed, status = 84
Unable to get target data at target 6 LUN 0, status = 84

Probing Target 7 ==========================================================

Target = 7. LUN = 0.
----------------------
Standard Inquiry failed, status = 84
Unable to get target data at target 7 LUN 0, status = 84

Probing Target 8 ==========================================================

Target = 8. LUN = 0.
----------------------
Standard Inquiry failed, status = a58 (SS$_NOMOREDEV)
None found on this port.
End of scan for port FGA.

</code>