Datastore Visibility Inconsistency Across ESXi Cluster Due to SCSI Reservation Conflicts and PowerPath Compatibility

Products

VMware vSphere ESXi

Issue/Introduction

Symptoms

New datastores were provisioned and added to a datastore cluster. Following presentation to the ESXi cluster, datastore visibility was inconsistent across hosts.
Only Few hosts successfully discovered and mounted the newly created datastores. The remaining hosts displayed the devices as Not Consumed and did not display datastore names.
It is observed that while datastores are successfully mounted by some hosts, others report the storage as "Not Consumed" or display "0 Bytes" within the vSphere Client.

Additional symptoms included:

Datastore visibility limited to a subset of hosts.
Datastore reported as Unmounted and Disconnected on specific hosts.
Delayed command execution and general management responsiveness degradation.
Dell PowerPath Management Appliance (PPMA) lost API/management communication with multiple ESXi hosts.
VMFS heartbeat failures reported in vmkernel logs.
SCSI reservation conflicts reported by PowerPath.
Inability to clear reservation keys from affected LUNs.

Environment

VMware ESXi 8.0 U3

Multipathing Software: Dell PowerPath 8.2 SP1

Storage Array: Dell PowerStore 4.4.

Cause

An incompatibility existed between the deployed Dell PowerPath configuration and the PowerStore 4.4 environment.

External initiators maintained active SCSI-3 Persistent Reservations on the affected shared LUNs. These reservations prevented ESXi hosts from obtaining the necessary access required to perform datastore discovery, partition reads, heartbeat updates, and VMFS mount operations.

PowerPath repeatedly attempted SCSI-2 reservation and release operations, resulting in reservation conflicts (SCSI status 0x18). The persistent reservation ownership prevented normal VMFS operations and caused datastore accessibility inconsistencies across the cluster.

Log Evidence

The following observations confirmed the cause:

Active SCSI-3 Persistent Reservations existed on all affected PowerStore LUNs.
Reservation keys were automatically re-created after LUN reset operations.
Reservation removal attempts failed because ownership remained active.
vmkernel logs showed repeated SCSI reservation conflicts (status 0x18).
VMFS heartbeat failures occurred simultaneously with reservation conflicts.
PowerPath management communication failures were observed on affected hosts.
Resource utilization remained normal, eliminating host performance bottlenecks.
After migrating to VMware Native Multipathing (NMP), all hosts successfully mounted and accessed the datastores.
No further reservation conflicts or heartbeat failures were observed.

The following error messages are frequently identified within the /var/log/vmkernel.log:

2026-05-26T06:44: 09.436Z Al (177) vmkalert: cpu42: 2868977) ALERT: PowerPath: EK###38: SCSI-2 release failed with SCSI status 0x18
2026-05-26T06: 44: 10.537Z Al (177) vmkalert: cpu42: 2868977) ALERT: PowerPath: EK###38: SCSI-2 release failed with SCSI status 0x18

2026-05-26T06:44:14.506Z In(182) vmkernel: cpu26:2097260)ScsiDeviceIO: 4670: Cmd(0x45b9bf5333c0) 0x28, cmdId.initiator=0x430947a98770 CmdSN 0x17c8b18 from
rld 0 to dev "naa.68##############################d6" failed H:0x5 D:0x0 P:0x0 . Cmd count Active:0 Queued:0
2026-05-26T06:44:14.506Z In(182) vmkernel: cpu2:2876252)Partition: 477: Failed read for "naa.68##############################d6": I/O error
2026-05-26T06:44:14.506Z In(182) vmkernel: cpu2:2876252)Partition: 1205: Failed to read protective mbr on "naa.68##############################d6" : I/O er

2026-05-19T06:30:54.549Z In(182) vmkernel: cpu56:4416182)HBX: 3089: 'Datastore4': HB at offset 3551232 - Waiting for timed out HB:
2026-05-19T06:30:54.549Z In(182) vmkernel: cpu56:4416182) [HB state ######### offset ######## gen 15 stampUS ############ uuid 69####50-########-####-002#######02 jrnl <FB 41943049> drv 24.82 lockImpl 3 ip 10.##.##.##]
2026-05-19T06:30:59.097Z In(182) vmkernel: cpu89:4424771)WARNING: FS3J: 3386: Error committing txn callerID: 0xc1d00015 to slot 1: IO was aborted by VMFS via a virt-reset on the device
2026-05-19T06:30:59.097Z In(182) vmkernel: cpu62:3932267)Fil6: 4308: 'Datastore4': Fil6 file IO (<FD c32 r8>) : IO was aborted by VMFS via a virt-reset on the device
2026-05-19T06:30:59.959Z In(182) vmkernel: cpu62:3932267)Fil6: 4270: ioCtx: 0x45da22bff1c0, world: #######, overallStatus: IO was aborted by VMFS via a virt-reset on the device, token: 0x0, tokenStatus: N, txnToken: 0x0, txnTokenStatus: N, totalIOSize: 1, maxIOLength: 1

Resolution

The migration of affected storage devices from PowerPath to VMware Native Multipathing (NMP) is required for resolution.

The following steps should be performed sequentially on each host:

Place ESXi host in Maintenance Mode.
Remove existing PowerPath claim rule using the following command:
esxcli storage core claimrule remove -r <Rule_ID>
(Note: The specific PowerPath rule ID, frequently 380, is identified via esxcli storage core claimrule list).
Add a new NMP claim rule for the PowerStore vendor/model:
esxcli storage core claimrule add -r <New Rule number> --type vendor --vendor DellEMC --model PowerStore --plugin NMP
Load the updated claim configuration:
esxcli storage core claimrule load
Execute claim rules to apply the configuration:
esxcli storage core claimrule run
Reboot ESXi host to finalize the transition of path ownership to NMP.
Exit Maintenance Mode and repeat process is for all remaining cluster hosts.

Additional Information

Validation: Active SCSI-3 Persistent Reservation (PR) registrations are checked using the command vmkfstools -L readkeys /vmfs/devices/disks/[naa_id].

vmkfstools -L readkeys /vmfs/devices/disks/naa.###########################
Registration Key(s)
Key 1 : fe77#######fle
Key 2 : fe77#######lee
Key 3 : fe77#######ala
Key 4 : fe77#######c03
Key 5 : fe77#######e9c
Key 6 : fe77#######7e4
Key 7 : fe77#######ala

LUN Reset: It is noted that a LUN reset (vmkfstools -L lunreset) may provide only temporary relief, as keys may be immediately re-registered by external clusters.

vmkfstools -L lunreset /vmfs/devices/disks/naa.###########################

Collaboration: This resolution was developed and validated through coordination between VMware/Broadcom and Dell PowerPath/PowerStore engineering teams.