Ошибка targetcli "WWN not valid as: naa" при попытке добавления в ACL конфигурации Linux-IO FC Target хостов FC Initiator с WWPN от виртуальных машин Hyper-V Gen2

LinuxIO Target and Hyper-V VM WWNВ одной из прошлых заметок мы уже упоминали о такой штуке, как 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:

targetcli error WWN not valid as naa

При этом попытки использовать разный регистр и разделители при указании 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 WWN check utils.py code

После правки, нужно перезапустить сеанс работы с утилитой targetcli.

При повторной попытке добавления в ACL идентификатора WWPN с виртуальной машины Hyper-V с выше обозначенной ошибкой мы уже не столкнёмся.

targetcli and Hyper-V WWPN

На самом деле с описанной проблемой скрипта utils.py я столкнулся ещё примерно полтора года назад при использовании пакета python3-rtslib-fb из репозиториев Debian 9, но отложил написание этой заметки "на потом". Но чуда за это время не произошло и "болячка не рассосалась".

Добавить комментарий