В одной из прошлых заметок мы уже упоминали о такой штуке, как Linux-IO (LIO) и показывали пример пакетного использования утилиты targetcli, которая используется для управления конфигурацией FC Target. Использование этой утилиты в типичном сценарии, когда хосты, выступающие в роли FC Initiator, являются физическими и имеют физические адаптеры FC HBA, не вызывает проблем. Однако, если в качестве Initiator мы попробуем добавить в конфигурацию LIO вместо физических FC HBA, виртуальные HBA из виртуальных машин Hyper-V, то здесь нам targetcli может выдать ошибку "WWN not valid as: naa". В этой заметке мы поговорим о том, почему возникает такая ошибка и как её обойти.
Итак, предположим, у нас есть некая виртуальная машина Hyper-V Gen2, подключённая через технологию NPIV, к сети FC SAN. На эту виртуальную машину мы хотим пробросить какое-то блочное устройство с физического сервера на базе Linux с помощью LIO FC Target. Для этого на стороне Linux-сервера с помощью утилиты targetcli в конфигурации LIO мы пытаемся прописать в лист доступа (ACL) идентификаторы vHBA WWPN виртуальной машины. Делаем это командой типа:
# targetcli /qla2xxx/naa.50014380062e3204/acls create C003FF9BFEE40008
В этом примере идентификатор "C003FF9BFEE40008" это WWPN vHBA нашей виртуальной машины. И здесь то мы и получим от targetcli ошибку несоответствия указанного идентификатора типу WWN:
При этом попытки использовать разный регистр и разделители при указании WWPN в этой ситуации нас не спасут.
Исследование проблемы показало, что код исполняемого скрипта /usr/lib/python3/dist-packages/rtslib_fb/utils.py, поставляемого в пакете python3-rtslib-fb и используемого утилитой targetcli, содержит вызов функции normalize_wwn. В этой функции имеется код, определяющий валидность идентификаторов разного типа. В нашем случае эта функция выполняет проверку в соответствии со строкой вида:
'naa': lambda wwn: re.match(r"naa\.[125][0-9a-fA-F]{15}$", wwn),
То есть если указанный нами идентификатор WWN/WWPN будет начинаться с цифровых символов "1","2" или "5", то, скорее всего, мы не столкнёмся с описанной ошибкой. В нашем же случае идентификаторы WWPN vHBA виртуальной машины Hyper-V начинаются с буквенного символа "С", что и вызывает "негодование" targetcli.
Правильным решением в этой ситуации будет обращение к разработчикам targetcli и исправление этой проблемы на глобальном уровне. Однако, вспоминая свои попытки получить отклик в мейл-группе LIO, можно предположить, что занятие это будет не интересное.
Чтобы решить эту проблему "здесь и сейчас" нам достаточно будет внести небольшую правку в выше обозначенную строчку скрипта utils.py, чтобы она приняла, например, следующий вид:
'naa': lambda wwn: re.match(r"naa\.[0-9a-fA-F]{16}$", wwn),
После правки, нужно перезапустить сеанс работы с утилитой targetcli.
При повторной попытке добавления в ACL идентификатора WWPN с виртуальной машины Hyper-V с выше обозначенной ошибкой мы уже не столкнёмся.
На самом деле с описанной проблемой скрипта utils.py я столкнулся ещё примерно полтора года назад при использовании пакета python3-rtslib-fb из репозиториев Debian 9, но отложил написание этой заметки "на потом". Но чуда за это время не произошло и "болячка не рассосалась".
RSS - Записи
Добавить комментарий