Connecting an HP Fiber Channel Tape Library to an ESXi 5.5 Host

In today's Mythbusters series, we’ll look at connecting the HP StoreEver Fiber Channel protocol library to an ESXi 5.5 host without additional cards and Direct path IO Passthrough.

Note: As per the vSphere 5.x Release Notes, VMware does not support Tape Drives connected directly to ESXi 5.x.

VMware, KB1016407

Does not support - does not mean does not work.

Anyway, nothing will work for you! Since VMware said it’s not supported, it’s not worth trying. I'd rather connect it directly to my beloved HP DL 580.

An incredulous administrator

This is not entirely true. Yes, we will create an unaccompanied configuration that runs on parole, but passes tests in the HPE Library and Tape Tools, is recognized and works in Veeam Backup and Replication . It is good to be healthy and rich when there is a physical server with FC HBA for backup. If, however, you need to make “out of the blue” work, if you want to figure out a little how the ESXi storage subsystem works, welcome to cat.

Let's start with a small introduction.

How the ESXi Storage Subsystem Works

Before you begin to understand why nothing works, you should refresh something in your memory. How the storage subsystem of the hypervisor is arranged, what utilities are used during configuration, and where to look for errors - this is what we will devote a few lines to.


The VMware Pluggable Storage Architecture Framework loads the Multipath Plugin, which is generally responsible for the I / O operations of certain device classes.
Two plug-ins are included with the hypervisor - Native Multipath Plugin (NMP) and the MASK_PATH stub plug-in, which hides unnecessary devices . Some vendors develop their own MP plugins, such as EMC PowerPath / VE or Symantec / Veritas DMP.

Nmpin turn, implements its functionality through the Path Selection Plugin (PSP) and Storage Array Type Plugin (SATP) plugins.

PSP deals directly with I / O and implements a policy of balancing traffic between multiple active paths. There are only three branded PSPs ( hence, politicians ) = MRU , RR , Fixed. There are also vendor PSPs. If an error occurs during the I / O operation, the PSP sends it to SATP, and SATP responds to it .

SATP is responsible for the selection of active (optimal) paths when working with a specific array, monitoring the state of paths; it responds to SCSI sense codesreturned by the array (some of the codes are the same, and some may vary from vendor to vendor). It is SATP that polls ALUA arrays with the RTPG command to select optimized paths. The behavior of the plugin is “tuned” with additional options.

For devices, rules have been created that determine which MP and SATP to process a particular device.
It sounds intricate, but in fact, everything is much simpler.

To work, you need to enable SSH on the ESXi host.

We ’ll get a list of:
MP plugins: SATP


plugins : PSP plugins : And this is how the puzzle assembly looks like:








Each detected storage device is “run” through a set of rules to select MP and SATP plugins.

MPP


selection rules: SATP selection rules:

esxcli storage nmp satp rule list

The list of rules is very long, I will give a useful excerpt from the list:



There are no PSP selection rules, for most SATP PSP is specified by default, and it can be changed manually from the interface.
The introductory part is finished, let's proceed to the first part - connecting the library.

Why can not you just take and connect the library

The HP library at the SCSI level is represented by the set of LUNs of one SCSI Target, for example:
LUN 0 - HP Fiber Channel Tape
LUN 1 - HP Fiber Channel Medium Changer

Let's review the manual:

Note: ESXi / ESX supports vendor-supported parallel SCSI tape drives and tape libraries only. If you are using a tape drive library (versus using a stand-alone tape drive), the library must be multi-target, and not multi-LUN. Ensure that the tape drive's virtual target ID in the virtual machine's configuration is set to be the same as the physical target ID.

VMware, KB1016407

Again not by the rules. HP StoreEver is a multi-LUN library, not a multi-target. But this will not stop us.

We connect the drive

We connect the library to the SAN switch, configure the zoning so that the library can see only one host and only one card. If it doesn’t work out - it's okay, we will mask it with a plugin.

We check that ESXi saw the streamer:

Immediately write down its identifier of the form naa. {Your identifier} .

We go to Manage Paths to understand which plug-in for working with arrays is selected for our device:


In our case, this is VMW_SATP_ALUA. At the same time, the plug-in works so well with the streamer that all paths to it at the same time are marked as dead. It is logical to assume that the streamer is somewhat alien to both ALUA and multipasing. Therefore, we will turn it into a simple local device.

Note: Since the VMW_SATP_LOCAL plugin is being used, only a single path to the device is supported.

VMware, KB1026157

What you need.

Let's see the NMP settings for the tape drive:

That's right, VMW_SATP_ALUA is used. Recall that the esxcli storage nmp satp rule list rules are responsible for choosing the SATP plugin.

If the device did not fall under a specific rule, then it will be processed by one of the “default” rules:


Logically, the device should fall under the “Fiber Channel Devices” rule, since the transport is “fc”, but in fact the plug-in is assigned by the rule “Any array with ALUA support. " Somewhere there is a catch, but it is not fundamental. Our task is to write such a rule for the streamer so that it is processed by the VMW_SATP_LOCAL plugin (usually processing local devices like usb, ide, block).

We will carefully look at our device using the command:

esxcli storage core device list

To create a rule, take the following unique streamer properties:
Vendor : HP
Model : Ultrium 5-SCSI

Write a rule:

esxcli storage nmp satp rule add --satp=VMW_SATP_LOCAL --vendor="HP" --model="Ultrium 5-SCSI"

Now you need to reinitialize all the available paths to the tape drive:

esxcli storage core claiming reclaim -d naa.{ваш идентификатор}

As a result, the host will use only one path to the device and only on one HBA:



In the virtual machine, add a new device:


Type of device "Tape HP":


Now you need to carefully select the Virtual Device Node. The rules are as follows :
- the target number must match the real number. In our case, this is Target 2.

- there should be no disk devices on the adapter port. Virtual machine hard disks are usually bound to port 0, so the first suitable port is 1: 2 (1 is the SCSI port number of the controller, 2 is the number of the tape drive target). VMware virtual SCSI controllers are dual-port. If you specify port 3 or 4, a new controller is automatically added.

Download the HP StoreEver Tape Drivers for Windows driver package . In a virtual machine, the package just does not install:


Unpack it 7zip and run setup.exe:

The streamer is ready in the device manager!

Connect the library

It is not enough to connect a streamer; for normal operation, you will need to see the library itself, also known as a “changer” or “robot” in the operating system.

As we can see from the list, the path to the library is missing:


Turn to the ESXi log:

tail -n 100 vmkwarning.log

NMP: nmp_SatpClaimPath:2093: SATP "VMW_SATP_ALUA" could not add  path "vmhba1:C0:T2:L1" for device "Unregistered Device". Error Not found

The SCSI Target ID of this unknown device matches the tape drive, but the LUN number is 1. Obviously, our library cannot recognize it. NMP tried to connect the library with the VMW_SATP_ALUA plugin, but nothing came of it.

This issue occurs because a catch-all SATP rule has claimed the device, which has registered it as ALUA.
VMware, KB1026157

We identify the device model:

esxcfg-rescan vmhba1
grep ScsiScan /var/log/vmkernel.log

016-07-20T06:30:37.502Z cpu6:33063)ScsiScan: 976: Path 'vmhba2:C0:T1:L1': Vendor: 'HP      '  Model: 'MSL G3 Series   '  Rev: '6.20'

Parameters we need:
Vendor: HP
Model: MSL G3 Series

Add a new rule for SATP:

esxcli storage nmp satp rule add --satp=VMW_SATP_LOCAL --vendor="HP" --model="MSL G3 Series"

Make unclaim for the path

esxcli storage core claiming unclaim -t location -A vmhba2 -C 0 -T 1 -L 1

Scan devices:

esxcfg-rescan vmhba

The path to the Medium Changer has been successfully added:


Add it to the virtual machine as “Media HP” on the same SCSI Target ID as the drive, but on a different controller port (2: 2).

The changer appeared in the virtual machine:


This is a victory.

If you need to mask the drive (the changer is optional, it will not be detected, as we have already seen) on other ESXi hosts, then proceed as in article KB1029786 . And if very briefly, then we add rules so that our device is processed instead of NMP by the MASK_PATH plugin.

esxcli storage core claimrule add -r 192 -t location -A vmhba{N} -C {C} -T {T} -L {0} -P MASK_PATH
esxcli storage core claimrule load
esxcli storage core claiming reclaim -d naa.{идентификатор привода}

Thanks for attention.
Did you know that you can now prioritize I / O Paths in the event of a failover
Pluggable Storage Architecture (PSA) Deep-Dive
If timeouts occur in Veeam Backup: https://www.veeam.com/kb1887