Lenovo DE Series with VMware ESXi over SAS: fix single-path visibility, ALUA/NMP claiming and controller management

Problem

A Lenovo ThinkSystem DE Series array is connected directly to VMware ESXi hosts over SAS, but the configuration does not provide the redundancy expected from the physical cabling.

Typical symptoms include:

• SAS links show Up, but ESXi sees only one path per LUN
• Devices may appear as degraded
• One SAS initiator is associated with the ESXi host while another is discovered but unassigned
• The array reports Volume Not On Preferred Path
• ESXi logs recurring messages where a path is already managed by NMP, while a generic SAS claim rule indicates HPP
• One storage controller is reachable through SAS data paths but its Ethernet management interface is unreachable
• NTP or management alerts appear even though storage I/O continues to work

The important point is that physical link state, multipath configuration and controller management are three separate layers.

Architecture

Treat the environment as three independent planes:

1. DATA PATH

ESXi HBA
   ↓
SAS cabling
   ↓
Controller A / Controller B
   ↓
LUNs

2. MULTIPATHING

ESXi
   ↓
NMP
   ↓
SATP / ALUA
   ↓
PSP Round Robin
   ↓
AO / ANO paths

3. MANAGEMENT

Storage controller Ethernet port
   ↓
Switch
   ↓
Management VLAN
   ↓
Gateway / DNS / NTP / management station

A controller can have healthy SAS data paths while its management Ethernet interface is misconfigured.

Expected state

For a validated dual-path design, the target state is similar to:

2 SAS initiators associated with each ESXi host
2 runtime paths per LUN
Device Status: on
Multipath Plugin: NMP
Storage Array Type: VMW_SATP_ALUA
Path Selection Policy: VMW_PSP_RR
1 path Active Optimized
1 path Active Non-Optimized
RTP_health=UP
Preferred controller ownership correct
No recurring HPP/NMP claiming warnings
Controller management reachable
Recovery Guru reports Optimal

Diagnostic workflow

1. Inventory adapters, devices and paths

On each ESXi host:

esxcli storage core adapter list
esxcli storage core device list
esxcli storage core path list
esxcli storage nmp device list

Also inspect the SAS HBA:

esxcli storage san sas list

Confirm the expected HBA, driver and storage devices are present.

2. Count paths per LUN

A quick method is:

esxcli storage core path list |
grep "Device: naa." |
awk '{print $2}' |
sort |
uniq -c

Adapt the filter to the relevant device IDs.

A dual-path design should normally show two paths for each presented LUN.

If ESXi sees only one path, continue with host-port mapping before changing multipathing policy.

3. Validate SAS initiators in Lenovo System Manager

Open the host object in Lenovo System Manager and inspect its host ports / SAS initiators.

A common failure pattern is:

SAS link: Up
Initiator: discovered
Host mapping: not assigned

This means the physical link exists, but the LUN is not presented to the host through that initiator.

Associate the correct discovered initiator with the correct ESXi host only after confirming the SAS address belongs to that host.

Do not move an already assigned initiator by trial and error.

4. Rescan ESXi

After correcting host-port mapping:

esxcli storage core adapter rescan --all

Then repeat:

esxcli storage core path list
esxcli storage core device list

Expected result:

2 paths per LUN
Status: on

If the host still sees a single path, investigate cabling, controller ports, target presentation and HBA visibility before changing claim rules.

5. Validate NMP, ALUA and Round Robin

For a representative LUN:

esxcli storage core device list -d <naa.ID>
esxcli storage nmp device list -d <naa.ID>
esxcli storage nmp path list -d <naa.ID>

A healthy Lenovo DE Series device may look like:

Multipath Plugin: NMP
Vendor: LENOVO
Model: DE_Series
Status: on
Is Local: false

Storage Array Type: VMW_SATP_ALUA
Path Selection Policy: VMW_PSP_RR

For ALUA, one path can be Active Optimized (AO) and another Active Non-Optimized (ANO).

A typical path state is:

Path A
Group State: active
TPG_state=AO
RTP_health=UP

Path B
Group State: active unoptimized
TPG_state=ANO
RTP_health=UP

If useANO=0, the PSP may list only the AO path under Working Paths. This does not necessarily mean there is only one physical/runtime path.

6. Check preferred controller ownership

In Lenovo System Manager, inspect:

Recovery Guru
Volumes
Preferred Owner
Current Owner

If Volume Not On Preferred Path appears, do not immediately run a manual redistribute.

First restore the missing path or host-port mapping and re-evaluate ownership.

The array may return volumes to the preferred controller automatically once the path topology is healthy.

7. Check HPP versus NMP claiming

ESXi 7.0 U2 and later changed default claiming behaviour for SAS devices in ways that can involve HPP. Broadcom documents SAS cases where remote arrays may need an explicit NMP claim rule. Broadcom reference

Inspect current rules:

esxcli storage core claimrule list
esxcli storage nmp satp rule list | grep -i -B 2 -A 2 LENOVO

Inspect recent logs:

grep -Ei "HPP|NMP|claim|claimrule" /var/log/vmkernel.log | tail -100

A recurring pattern may look similar to:

Path ... is claimed by plugin NMP,
but current claimrule indicates that it should be claimed by plugin HPP.

Before adding any vendor rule, confirm the device identity:

esxcli storage core device list -d <naa.ID> |
grep -E "Multipath Plugin:|Vendor:|Model:|Status:|Is Local:"

8. Add a specific NMP claim rule when required

Broadcom documents using a vendor/model rule below rule 50 for affected remote SAS arrays. Broadcom reference

Example for Lenovo DE Series:

esxcli storage core claimrule add \
-r 49 \
-t vendor \
-V LENOVO \
-M DE_Series \
-P NMP \
--force-reserved

esxcli storage core claimrule load

Validate:

esxcli storage core claimrule list

Expected pattern:

49 runtime vendor NMP vendor=LENOVO model=DE_Series
49 file    vendor NMP vendor=LENOVO model=DE_Series

Important safety note

Adding and loading the rule is not the same as forcing an active device through an unclaim/reclaim cycle.

Do not execute storage core claiming unclaim, claimrule run or a host reboot on production datastores without a maintenance plan.

Broadcom documentation explicitly notes that reclaim or reboot may be required in some cases for a new claim rule to take effect, so treat those operations as potentially disruptive. Broadcom reference

9. Validate that recurring claiming warnings stop

Record the time:

date -u

Then re-check:

grep -Ei "claimed by plugin NMP|claimrule" /var/log/vmkernel.log | tail -20

If warnings previously occurred at a regular interval, wait beyond that interval and confirm no new events appear.

10. Validate controller management separately

If one controller is not reachable over Ethernet, do not assume a SAS problem.

Check:

• switch MAC table
• port link state
• speed and duplex
• access VLAN / PVID
• ARP on the gateway
• NTP request/reply

A common failure is:

Controller IP belongs to Management VLAN A
Switch access port is untagged in VLAN B
→ ARP fails
→ management ping fails
→ NTP fails

Correct the access VLAN / PVID only after confirming the expected management subnet.

11. Final validation

On every ESXi host, confirm:

esxcli storage core path list
esxcli storage core device list
esxcli storage nmp device list -d <naa.ID>
esxcli storage nmp path list -d <naa.ID>
esxcli storage core claimrule list

Target state:

[ ] expected paths per LUN
[ ] devices Status: on
[ ] NMP
[ ] VMW_SATP_ALUA
[ ] VMW_PSP_RR
[ ] AO + ANO healthy
[ ] RTP_health=UP
[ ] preferred ownership healthy
[ ] no new HPP/NMP warnings
[ ] controller management reachable
[ ] Recovery Guru reports Optimal

Performance versus resilience

This distinction is critical.

A storage configuration can be wrong from a resilience perspective without being the cause of an application performance incident.

Examples:

single-path            ≠ proof of storage bottleneck
device degraded flag   ≠ proof of high latency
NTP failure            ≠ proof of I/O latency
claim-rule warning     ≠ proof of application slowness

If ESXi DAVG/GAVG, Windows disk latency and array-side latency remain low during the incident, do not retroactively label the storage configuration as the root cause.

Correct the resilience issue, then repeat the same workload and compare before/after measurements.

Round Robin note

Lenovo documents that DE Series arrays commonly use VMware NMP with Round Robin and that lowering the Round Robin I/O counter from the default value can improve host-side latency in specific workloads. This is a tuning option, not a mandatory setting, and should only be changed after measurement and vendor validation. Lenovo reference

Rollback and change control

Potentially disruptive actions include:

• unclaiming active devices
• forcing reclaim
• changing SATP/PSP on active LUNs
• rebooting ESXi hosts
• changing storage ownership by trial
• modifying SAS links during I/O

Perform those only with:

• current backups
• maintenance window
• rollback plan
• verified vendor/model match
• validation on every host

Sources

See the Broadcom and Lenovo references in the article metadata.