В сегодняшней серии «Разрушителей мифов» мы рассмотрим тему подключения ленточной библиотеки HP StoreEver по протоколу Fibre Channel к хосту ESXi 5.5 без дополнительных карт и 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

Не поддерживает — не значит не работает.

Да все равно у вас ничего работать не будет! Раз VMware сказала — не поддерживается, не стоит и пробовать. Я лучше подключу ее напрямую к моему любимому HP DL 580.

Недоверчивый администратор

Это не совсем так. Да, мы создадим несопровождаемую конфигурацию, которая работает на честном слове, но проходит тесты в утилитах HPE Library and Tape Tools, распознается и работает в Veeam Backup and Replication. Хорошо быть здоровым и богатым, когда есть физический сервер с FC HBA для бэкапа. Если же из пустоты надо сделать «чтобы работало», если вы хотите немного разобраться как устроена подсистема хранения ESXi — добро пожаловать под кат.

Начнем с небольшой вводной части.

Как устроена подсистема хранения ESXi

Прежде чем начать разбираться почему ничего не работает, следует освежить кое-что в памяти. Как устроена подсистема хранения гипервизора, какие утилиты используются при настройке и где искать ошибки — именно этому мы посвятим несколько строк.


VMware Pluggable Storage Architecture Framework загружает Multipath Plugin, в целом ответственный за операции ввода-вывода определенных классов устройств.
В комплекте с гипервизором идут два плагина — Native Multipath Plugin (NMP) и плагин-заглушка «MASK_PATH», скрывающий ненужные устройства. Некоторые вендоры разрабатывают собственные MP-плагины, такие как EMC PowerPath/VE или Symantec/Veritas DMP.

NMP свою очередь реализует свою функциональность через плагины Path Selection Plugin (PSP) и Storage Array Type Plugin (SATP).

PSP занимается непосредственно вводом-выводом и реализует политику балансировки трафика между множественными активными путями. Фирменных PSP (следовательно и политик) всего три = MRU, RR, Fixed. Существуют и вендорские PSP. Если во время операции ввода-вывода происходит ошибка, PSP передает ее в SATP, а SATP реагирует на нее.

SATP отвечает за выбор активных (оптимальных) путей при работе с конкретным массивом, мониторинг состояния путей; он реагирует на SCSI Sense-коды, возвращаемые массивом (часть кодов одинакова, а часть может варьироваться от вендора к вендору). Именно SATP опрашивает ALUA массивы командой RTPG для выбора оптимизированных путей. Поведение плагина «тюнингуется» дополнительными опциями.

Для устройств созданы правила, которые определяют, каким именно MP и SATP обрабатывать то или иное устройство.
Звучит замысловато, но на деле все гораздо проще.

Для работы вам потребуется включить SSH на хосте ESXi.

Получим список:
плагинов MP:


плагинов SATP:


плагинов PSP:


А вот так выглядит паззл в сборе:


Каждое обнаруженное устройство хранения «прогоняется» через набор правил, чтобы выбрать плагины MP и SATP.

Правила выбора MPP:


Правила выбора SATP:

esxcli storage nmp satp rule list

Список правил очень длинный, приведу полезную выдержку из списка:



Правил выбора PSP нет, для большинства SATP указан PSP по умолчанию, и его можно поменять вручную из интерфейса.
Вводная часть закончена, приступим к первой части — подключению библиотеки.

Почему нельзя так просто взять и подключить библиотеку

Библиотека HP на уровне SCSI представлена набором LUN одного SCSI Target, например:
LUN 0 — HP Fibre Channel Tape
LUN 1 — HP Fibre Channel Medium Changer

Сверимся с методичкой:

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

Опять не по правилам. HP StoreEver именно multi-LUN библиотека, а не multi-target. Но и это нас уже не остановит.

Подключаем привод

Подключаем библиотеку к SAN-коммутатору, настраиваем зонирование так, чтобы библиотеку видел только один хост и только одной картой. Если не получится это сделать — ничего страшного, замаскируем плагином.

Проверяем, что ESXi увидел стример:

Сразу запишите его идентификатор вида naa.{ваш идентификатор}.

Заходим в Manage Paths чтобы понять, какой плагин для работы с массивами выбран для нашего устройства:


В нашем случае это VMW_SATP_ALUA. При этом плагин так удачно работает со стримером, что все пути к нему заодно пометились как мертвые. Логично предположить, что стримеру несколько чужд как ALUA, так и мультипасинг. Поэтому будем превращать его в простое локальное устройство.

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

VMware, KB1026157

То, что надо.

Посмотрим настройки NMP для стримера:

Все верно, используется VMW_SATP_ALUA. Вспомним, что за выбор плагина SATP отвечают правила esxcli storage nmp satp rule list.

Если устройство не попало под конкретное правило, то оно обработается одним из правил «по умолчанию»:


По логике устройство должно было попасть под правило «Fibre Channel Devices», так как транспорт — «fc», но по факту плагин назначен правилом «Any array with ALUA support». Где-то здесь есть подвох, но он не принципиален. Наша задача — написать такое правило для стримера, чтобы он обрабатывался плагином VMW_SATP_LOCAL (обычно обрабатывающим локальные устройства типа usb, ide, block).

Посмотрим внимательно на наше устройство с помощью команды:

esxcli storage core device list

Для создания правила возьмем следующие уникальные свойства стримера:
Vendor: HP
Model: Ultrium 5-SCSI

Пишем правило:

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

Теперь нужно переинициализировать все имеющиеся пути к стримеру:

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

В результате хост будет использовать только один путь до устройства и только на одной HBA:



В виртуальной машине добавляем новое устройство:


Тип устройства «Tape HP»:


Теперь необходимо аккуратно выбрать Virtual Device Node. Правила следующие:
— номер таргета должен совпадать с реальным номером. В нашем случае это Target 2.

— на порту адаптера не должно быть дисковых устройств. Жесткие диски виртуальной машины как правило привязаны к порту 0, поэтому первый подходящий порт это 1:2 (1 — номер порта SCSI контроллера, 2 — номер таргета стримера). Виртуальные SCSI-контроллеры VMware — двухпортовые. Если вы зададите порт 3 или 4, автоматически добавится новый контроллер.

Скачиваем пакет драйверов HP StoreEver Tape Drivers for Windows. В виртуальной машине пакет просто так не установится:


Распакуем его 7zip и запустим setup.exe:

В диспетчере устройств стример готов!

Подключаем библиотеку

Мало подключить стример, для нормальной работы потребуется увидеть в операционной системе и саму библиотеку, так же известную как «ченджер» или «робот».

Как мы видим из списка, путь до библиотеки отсутствует:


Обратимся к журналу ESXi:

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

SCSI Target ID этого неизвестного устройства совпадает со стримером, а вот номер LUN равен 1. Очевидно, что распознаться не может как раз наша библиотека. NMP попробовал подключить библиотеку плагином VMW_SATP_ALUA, но ничего не вышло.

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

Идентифицируем модель устройства:

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'

Нужные нам параметры:
Vendor: HP
Model: MSL G3 Series

Добавим новое правило для SATP:

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

Сделаем unclaim для пути

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

Пересканируем устройства:

esxcfg-rescan vmhba

Путь к Medium Changer успешно добавлен:


Добавляем его в виртуальную машину как «Media HP» на тот же SCSI Target ID, что и привод, но на другой порт контроллера (2:2).

Чейнджер появился в виртуальной машине:


Это победа.

Если вам нужно замаскировать привод (чейнджер необязательно, он сам не определится, как мы уже увидели) на других хостах ESXi, то действуем как в статье KB1029786. А если совсем коротко, то мы добавляем правила, чтобы наше устройство обрабатывалось вместо NMP плагином MASK_PATH.

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.{идентификатор привода}

Спасибо за внимание.
Did you know that you can now prioritize I/O Paths in the event of a failover
Pluggable Storage Architecture (PSA) Deep-Dive