Избавляемся от HP LOGICAL VOLUME Multi-Path Disk Device : Отключение MPIO для локальных RAID-дисков HPE Smart-Array

Разбираясь с вопросом мониторинга доступности путей MPIO в Windows Server обнаружилось, что на некоторых хостах виртуализации имеется диск, включенный в MPIO, но имеющий при этом всего один путь. Обычно MPIO используется для дисков, подключенных одновременно по нескольким путям с внешних СХД из SAN, которые, как правило, используются в кластерных конфигурациях. Но тут сразу возникло подозрение о том, что в конфигурацию MPIO попал локальный диск сервера, не имеющий по сути отношения к логике Multi-Path.

То есть, в нашем случае локальный RAID-диск на базе контроллера HPE Smart-Array отображается в оснастке Device Manager с говорящим за себя названием "HP LOGICAL VOLUME Multi-Path Disk Device":

Выглядит такая конфигурация не очень хорошо, так, получается, что работа хостовой ОС с таким диском выполняется не напрямую, а через механизм MPIO. И, возможно, это объясняет ранее замеченные на SCOM алерты "Windows Storport Miniport Driver has timed out a request", полученные по этому серверу. Попробуем исправить эту ситуацию.

С помощью PowerShell командлета Get-MPIOAvailableHW можно посмотреть перечень дисков, которые, по мнению MSDSM, относятся к тем, что можно использовать для Multi-Path.

С помощью другого командлета Get-MSDSMSupportedHW можно увидеть идентификаторы оборудования (ProductId и VendorId), поддерживаемого модулем MSDSM. Ту же самую информацию мы сможем увидеть в апплете панели управления MPIO на первой вкладке "MPIO Devices":

В нашем случае MPIO нужен лишь для дисков подключённых к хосту с СХД по протоколу FibreChannel. И очевидно, что появление в перечне активных идентификаторов MSFT2005 iSCSIBusType_0x9 и

MSFT2011 SASBusType_0xA связано с ранее включёнными (без реальной на то необходимости) опциями "Add support for iSCSI devices" и "Add support for SAS devices" на вкладке "Discover Multi-Paths":

Переведём хост в обслуживание, сняв с него всю продуктивную нагрузку и выполним отключение двух выше обозначенных опций путём удаления соответствующих идентификаторов на вкладке "MPIO Devices":

Тоже самое можно сделать с помощью PowerShell:

Remove-MSDSMSupportedHW -VendorId "MSFT2005" -ProductId "iSCSIBusType_0x9"
Remove-MSDSMSupportedHW -VendorId "MSFT2011" -ProductId "SASBusType_0xA"
Update-MPIOClaimedHW -Confirm:$false

После этого для вступления изменений в силу потребуется выполнить перезагрузку сервера. При этом замечено, что после изменения конфигурации MPIO для диска, на котором расположена загружаемая хостовая ОС, после первой перезагрузки система может не загрузиться с первого раза. В этом случае не стоит сразу делать лишних телодвижений, а можно просто попробовать ещё раз перезагрузить систему.

После успешной загрузки хостовой ОС снова заглянем в оснастку Device Manager и убедимся в том, что теперь устройство локального RAID-диска отображается без упоминания Multi-Path. Например,  в нашем случае название изменилось на "HP LOGICAL VOLUME SCSI Disk Device" и в его свойствах пропала вкладка MPIO:

Подобное переключение диска с Multi-Path Disk Device на SCSI Disk Device было проверено как на дисках с MBR, так и на дисках с GPT для хостов с ОС Windows Server 2016 и Windows Server 2022.

При этом замечено, что после перезагрузки разделы без ОС могут перейти в состояние Offline. Чтобы их вернуть в работу, достаточно будет в оснастке управления дисками перевести их в Online: