Error: Failed to expand VMFS datastore Datastore_Name - Failed to update disk partitions for /vmfs/devices/disks/naa.###########################.
# vmkfstools -Ph -v 10 /vmfs/volumes/Datastore_Name
VMFS-5.61 (Raw Kajor Version: 14) file system spanning 3 partitions.
File system label (if any) : Datastore_Name
Mode: public ATS-only
apacity 24 TB, 9 MB available, file block size 1 MB, max supported file size 62.9 TB
Volume Creation Time: Thu Jan 16 09:48:54 2020
Files [max/free) : 130000/129809
Per Blocks (max/free) : 64512/39881
Bub Blocks (max/free) : 32000/31974
econdary Ptr Blocks [max/free) : 256/256
File Blocks (overcommit/used/overcommit 4) : 0/25165047/0
(overcomit/used/overcommit $) : 0/24631/0
(overcomit/used/overcommit 4) : 0/26/0
Volume Metadata size: 932544512
Diak Block Size: 512/512/0
JUID: ########-########-####-############
Partitions spanned (on "ivm") :
naa. ################################:1
naa. ################################:1
naa. ################################:1
Unable to connect to vaai-nasd socket [No such file or directory]
s Native Snapshot Capable: NO
OBJLIB-LIB: Objlib cleanup done.
ORKER: asyncOps=0 maxActiveOps=O maxPending=O maxCompleted=O
# partedUtil getUsableSectors /vmfs/devices/disks/naa.####################
Error: The backup GPT table is not at the end of the disk, as it should be.This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup) ?
Warning: Not all of the space available to /dev/disks/naa.###################### appears to be used, you can fix the GPT to use all of the space (an extra 8589934592 blocks) or continue with the current setting? This will also move the backup table at the end if it is not at the end already. diskSize (21474836480) AlternateLBA (12884901887) LastUsableLBA (12884901854) NewLastUsableLBA (21474836446)
34 21474836446
VMware vSphere ESXi 7.0.x
This issue can be caused by the backup GPT table not at the end of the disk after backend storage lun size is increased
GPT is a partitioning scheme that allows disks larger than 2 TB and provides redundancy with a primary GPT table (located at the start of the disk) and a backup GPT table (located at the end of the disk).
The backup GPT table is supposed to be placed at the very last sector of the disk, ensuring redundancy in case the primary table is damaged. The backup table is meant to be a copy of the main partition table located at the end of the disk.
The error indicates backup GPT table is not where it should be, which can indicate corruption, an incorrect partitioning layout, or a misalignment issue on the metadata level or on the partition level of the LUN.
The message about "another operating system believes the disk is smaller" suggests that there may be a misalignment between how the disk is being interpreted by the system.
This usually occurs when a disk has been expanded, and the backup GPT table has not been updated to reflect the new size. When a disk is expanded (e.g., after adding more physical disks to a LUN from storage array side), the system needs to update the backup GPT table to reflect the new size.
If the backup GPT table has not been moved to the end of the expanded disk or update the backup GPT table, the system might be confused about the disk's size, leading to this error message.
As this happens on metadata of the LUN and ESXi host does not have write access on it, hence vmkernel does not write anything on the log regarding the same.
To fix this issue need to run the fixgpt command.
If the symptoms above align with your issue, please contact Broadcom Support by opening a new support ticket for assistance in validating the partition size and grow the filesystem on the newly added capacity.
To validate the partition table on the storage device. Refer to this article for more information: https://knowledge.broadcom.com/external/article/321398/failed-to-expand-vmfs-datastore-cannot.html