Datastore extent appear as "Not Consumed" on cluster hosts after expansion via Host Client

Products

• VMware vCenter Server

Issue/Introduction

Symptoms:

• After expanding a VMFS datastore by adding a new extent using the Host Client 
• Navigate to other hosts in the same cluster. Select Configure and storage devices. Datastore section of the same LUN detect as "Not Consumed".
  

Environment

VMware vSphere ESXi 8.x

Cause

This issue occurs when a cluster-level storage rescan not performed after expanding the datastore from host client.

• When a datastore is mounted across multiple clusters and all the hosts have not been rescanned after the size of the LUN has been increased either by extending the same LUN or by adding new extent. Subsequently, if a write is attempted to the extended part of the volume, from a host which has not been rescanned then it will trigger a warning "Address temporarily unmapped" because it has determined that the addressed part of the device is unavailable.

Cause validation:

• Running the below mentioned command from the affected host reports the newly added LUN as offline. 
  vmkfstools -Ph -v10 vmfs/volumes/DATASTORE_NAME
VMFS-6.81 (Raw Major Version: 24) file system spanning 6 partitions.
File system label (if any): DATASTORE_NAME
Mode: public ATS-only
Capacity 6 TB, 1.3 TB available, file block size 1 MB, max supported file size 64 TB
Volume Creation Time: Thu Jul 21 08:55:56 2022
Files (max/free): 16384/16191
Ptr Blocks (max/free): 0/0
Sub Blocks (max/free): 16384/15868
Secondary Ptr Blocks (max/free): 256/255
File Blocks (overcommit/used/overcommit %): 0/4915348/0
Ptr Blocks  (overcommit/used/overcommit %): 0/0/0
Sub Blocks  (overcommit/used/overcommit %): 0/516/0
Large File Blocks (total/used/file block clusters): 12285/9581/627
Volume Metadata size: 1609080832
Disk Block Size: 512/512/0
UUID: ########-########-####-############
Logical device: ########-########-####-############
Partitions spanned (on "lvm"):
        naa.##############################:1
        naa.##############################:1
        naa.##############################:1
        naa.##############################:1
        naa.##############################:1
        (device naa.##############################:1 might be offline)
        (One or more partitions spanned by this volume may be offline)
Is Native Snapshot Capable: NO
OBJLIB-LIB: ObjLib cleanup done.
WORKER: asyncOps=0 maxActiveOps=0 maxPending=0 maxCompleted=0


• The var/run/log/vobd.log file reports that the datastore is in degraded state since one of the extent may be is offline
  2025-12-30T10:12:24.557Z In(14) vobd[2098383]:  [vmfsCorrelator] 3530303357352us: [vob.vmfs.extent.offline] An attached device went offline. naa.##############################:1 file system [DATASTORE_NAME, ########-########-####-############]
2025-12-30T10:12:24.557Z In(14) vobd[2098383]:  [vmfsCorrelator] 3530442282375us: [esx.problem.vmfs.extent.offline] An attached device naa.##############################:1 may be offline. The file system [DATASTORE_NAME, ########-########-####-############] is now in a degraded state. While the datastore is still available, parts of data that reside on the extent that went offline might be inaccessible.


• The var/run/log/vmkernel.log file confirms that the device went offline
  2025-12-30T10:12:24.556Z Wa(180) vmkwarning: cpu191:2100619 opID=106e1cc0)WARNING: LVM: 17690: An attached device went offline. naa.##############################:1 file system [g, ########-########-####-############]


• The var/run/log/vmkernel.log file also reports "Address temporarily unmapped".
  2026-01-02T07:22:12.788Z Wa(180) vmkwarning: cpu46:28990779)WARNING: LVM: 17690: An attached device went offline. naa.##############################:1 file system [DATASTORE_NAME, ########-########-####-############]
2026-01-02T07:22:13.016Z In(182) vmkernel: cpu46:28990779)Fil6: 4179: 'DATASTORE_NAME': Fil6 file IO (<FD c0 r1>) : Address temporarily unmapped
2026-01-02T07:22:13.016Z In(182) vmkernel: cpu46:28990779)Fil6: 4141: ioCtx: 0x45bbdfb50580, world: 28990779, overallStatus: Address temporarily unmapped, token: 0x0, tokenStatus: N, txnToken: 0x0, txnTokenStatus: N, totalIOSize: 1048576, maxIOLength: 90308608
2026-01-02T07:22:13.016Z In(182) vmkernel: cpu46:28990779)Fil6: 4149: numAddrs: 0, numTbz: 0, numPBsToAlloc: 0, numBlocksToAlloc: 0 numTBZBlocks: 0, numPBsToUnmap: 0, numBlocksToUnmap: 0
2026-01-02T07:22:13.016Z In(182) vmkernel: cpu46:28990779)Fil6: 4155: opType: 1, ioFlags: 264, allocFlags: 0, ioStateTxn: 0, ioStateNoTxn: 1, txnState: 2, numResolvedAddrMaps: 16, numTxnPendingAddrMaps: 0
2026-01-02T07:22:13.016Z In(182) vmkernel: cpu46:28990779)Fil6: 4162: wakeupOnIOComplete: 12, isIOIssued: 0, isIODone: 0, isRead: 1 isSync: 1, canBlock: 1, lastPartialBlock: 0

Resolution

Perform a cluster level storage rescan.

Cluster level storage rescan will trigger all hosts to detect the new LUN and new size of the datastore.

Additional Information

After a datastore is expanded from the ESXi host client or CLI, one or more hosts report "Device shrank" and the datastore becomes inaccessible