Hi,
sometimes the vSphere Client does not determine when an underlying Volume is expanded. So you cannot expand the datastore by the WebGUI or vSphere Client.
But the command line way is still possible 🙂 These are the steps:
In this example the underlying volume/LUN of datastore_0 was already expand from 6TB to 10TB at the storage system. So I also want to grow up the vmfs on datastore_0 to 10TB.
Login to an ESXi Host by ssh.
Rescan all storage adapter for changes
[root@esxihost:~] esxcli storage core adapter rescan --all
Determine the disk path
[root@esxihost:~] vmkfstools -P /vmfs/volumes/datastore_0 VMFS-5.61 file system spanning 1 partitions. File system label (if any): datastore_0 Mode: public Capacity 6596801331200 (6291200 file blocks * 1048576), 217090883584 (207034 blocks) avail, max supported file size 69201586814976 UUID: 5ad58cdb-c8604cf3-e8fc-a0369f990590 Partitions spanned (on "lvm"): naa.523545670e392ba2e81404da45912d543:1 Is Native Snapshot Capable: YES
Depending on the output of vmkfstools the Diskpath is /vmfs/devices/disks/naa.523545670e392ba2e81404da45912d543, :1 means datastore_0 is the first partition on the disk.
Get the Disk layout
[root@esxihost:~] partedUtil get /vmfs/devices/disks/naa.523545670e392ba2e81404da45912d543 1336746 255 63 21474836480 1 2048 12884901854 0 0
Start Sector of the first partition is 2048, current end sector is 12884901854 .
Determine the last usable end sector. If an error occured like this:
[root@esxihost:~] partedUtil getUsableSectors /vmfs/devices/disks/naa.523545670e392ba2e81404da45912d543 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)? This will also fix the last usable sector as per the new size.
then you have to correct the GPT partition table first:
[root@esxihost:~] partedUtil fixGpt /vmfs/devices/disks/naa.523545670e392ba2e81404da45912d543 FixGpt tries to fix any problems detected in GPT table. Please ensure that you don't run this on any RDM (Raw Device Mapping) disk. Are you sure you want to continue (Y/N): y gpt 1336746 255 63 21474836480 1 2048 12884901854 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
And again. Determine the last usable sector
[root@esxihost:~] partedUtil getUsableSectors /vmfs/devices/disks/naa.523545670e392ba2e81404da45912d543 34 21474836446
Last usable sector is 21474836446.
Expand the first partition. 2048 is the start sector and 21474836446 the new end sector.
[root@esxihost:~] partedUtil resize /vmfs/devices/disks/naa.523545670e392ba2e81404da45912d5431 1 2048 21474836446
and also grow the filesystem
[root@esxihost:~] vmkfstools --growfs /vmfs/devices/disks/naa.523545670e392ba2e81404da45912d543:1 /vmfs/devices/disks/naa.523545670e392ba2e81404da45912d543:1
rescan all volumes
[root@esxihost:~] vmkfstools -V
That’s it 🙂
Michael
Thank you so much!
The VMWare KB didn’t explain what to do if one runs into the GPT issue. Your blog helped me take care of this. Kudos to you, sir!
This solution worked perfectly for me.
Thanks a lot!
Thanks it worked for me too!
This was perfect. The Web UI was unable to scan the devices and populate it while I tried to “Increase Capacity” of the datastore. I also ran into the GPT issue. Thanks a lot! I was worried we had wasted a bunch of money in getting a new SSD.
thanks, this saved me!!
thanks, everything works.
it worked for me also. But with esxi 7 I had to unregister all VMs, unmount datastore, grow with your procedure and mount + register VMs
Worked like a charm. Thank you very much for that post 🙂
Thank you for this excellent post !
Hi, what about the vm actually on the datastore? Do I have to shitdown it? The datastore content will be lost??
Thanks
Hi Pierre,
no, the operation is non disruptive. All VMs on the datastore are not affected by this task and keep online.
Michael
Thanks very much. Your proceedure is complete whereas VMWares KB was not.
Many Many tanks.. very clear and useful procedure
well done