Для IP так можно
Beginning with ONTAP 9.7, MetroCluster IP configurations can support switches that are not NetApp validated provided that they are compliant with NetApp specifications.
https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-mcc-inst-cnfg-ip%2FGUID-D3FDF2D1-A056-4DC4-8C35-DDBC74A5F5CA.html

Точно не работает provider от NetApp? Я не уверен, отличаются ли они для версий SANtricity. У Lenovo крайняя версия SANtricity сейчас 11.60.2. Я задал вопрос на уточнение, проверьте и вы со своей стороны.

Еще один момент, проверьте состояние параметра restOnly:

set storageArray managementInterface restOnly={true | false}

Parameters
Parameter  Description
restOnly  When set to true , indicates that the RESTful interface is the only management interface allowed. This interface enforces an encrypted connection between the storage array and the management software.
When set to false , indicates that the legacy interface between the storage array and the management software is allowed. This interface is not encrypted.
Some tools that communicate directly with the legacy management interface, such as the ThinkSystem SAN OS SMI-S Provider or OnCommand Insight (OCI), will not work unless the restOnly parameter is set to false . Contact technical support for more information.
Examples

SMcli -n Array1 -c "set storageArray managementInterface restOnly=true;"

SMcli completed successfully.

Антон, я поизучал повнимательнее провайдер. Наверное можно сделать вывод, что сам провайдер работает. Если утилитой командной строки из пакета провайдера опрашивать сторейж, то данные возвращаются вполне релевантные. Диски, модели, состояние.
Сторейж зарегистрирован в namespace /root/NetApp/Santricity.

При этом SCVMM 2019 выписывает бороду WsManMIInvokeFailed ID:26263. Типа класс не вернулся? Библиотека Technet нам говорит что никакие Santricity не поддерживает ни vmm2016, ни vmm2019.
Технически я так полагаю, что возможно  SCVMM ищет объекты в namespace root/cimv2, не находит, и это причина ошибки.
То есть в том что данные smi-s хранилка отдает - уже сомнений нет.
То, что scvmm 2019 умеет ими пользоваться -  сомнения.

Нашествие ботов

Можно, если в России и модели полностью совпадают с коммутаторами из канала нетапп.

Просто так взять  произвольные коммутаторы  конечно нельзя;)

полностю совпадают, имеется ввиду партнамбер?
Можно ли использовать их параллельно в нашей сети и в организации кластера?

Модель циски .;)

Нет, нельзя - это всегда выделенные коммутаторы.

понятно, спасибо

А зачем? Там всей конфигурации на 15 минут..

Да скорее из научного интереса. Да, Santricity штука примитивная, и подать пару лунов и 4 iscsi пути дело получаса.
Просто никогда не было Santricity и SC VMM, только Netapp и vCenter. В общем я сделал вывод, что упорство в этом вопросе - дело тупиковое. Время уходит, выгоды нет.

Лучший ответ )

Я, кстати, пересчитал, память меня подвела: не 130, а 260 )) 130 – это на 32gbps

Что за дичь :) размер фрейма на всех скоростях одинаковый, до 2к

В FC Comprehensive Guide есть более адекватная математика как считать количество кредитов для длинных линков

Можно ссылку? Гугл что-то не то показывает. Ну, или более полное название.

Вот как-то так

https://www.google.ru/url?sa=t&source=web&rct=j&url=https://docs.broadcom.com/doc/12380259&ved=2ahUKEwjNjqOz9oftAhXC-yoKHX_QAXQQFjAAegQIARAB&usg=AOvVaw0yY_op6Iu1saozzyx-ta-E
Старенька белая бумажка, но...

спасибо!

Это если появится вопрос, что за 6 в формуле

От нашего стола, как говорится: “As per the table, to operate a 16-Gbps Fibre Channel ISL over 50 km, you would multiply the one way distance (50) times the number of BB_credits per km (8). That is, a 50 km 16-Gbps ISL requires 400 BB_credits. This is the minimum number of BB_credits that are required for the link to function at its best when utilized to its maximum. To accommodate a shorter average frame size than the maximum (full sized) value, more BB_credits would be required proportionally. Since each buffer is for a Fibre Channel frame irrespective of its size, when Fibre Channel frames are not full sized, more BB_credits are required to achieve full link utilization. In this case, an approximate yet simple formula for calculating BB_credits is the following:
BB_credits = (Interface operating speed (Gbps) x One-way Distance (km)) / Average frame size (KB)
The following example displays the BB_credits calculation for a 16 Gbps link that is 50 km long with an average frame size on receive side of 1 KB:
(16 (Gbps) x 50 (km)) / 1 (KB) = 800 BB_credits”