Recently after building my home lab, I was monitoring the memory resources and noticed that I’m getting too low available memory. As the cluster has only 48 GB, I’m always trying to optimize its usage. So after digging into esxtop stats, I found out the RAM drives were eating a substantial amount as booting from USB always causes this. I googled a bit but it seems it wasn’t my lucky day. In fact, I found several posts in VMware related blogs where people are asking for this. I thought it shouldn’t be possible not to be able to use an additional VMFS partition on the USB drive as there was lots of free space after deploying the OS. During these tests, I had to start over 3 times due to some design limitation. However at the end managed to succeed.

First tool I’ve tried with was Paragon Hard Disk Manager – this one changed the ID of the default ESXi partitions from 1,5,6,7,8 into 1,2,3,4,5 and as a consequence , ESXi couldn’t boot. So next tool (actually several) was to use Ubuntu in a VM workstation and gparted. The partition I created was at the end of the USB drive, leaving some free space in between just in case I need to extend a partition in future:

When creating the partition, do not create a FS. We’ll do this later with fdisk as gparted doesn’t support VMFS and custom IDs cannot be specified:

Note the new partition ID /dev/sdb2 below:

Next is to create VMFS custom ID on partition 2 (/dev/sdb2) with gdisk (recent versions of fdisk support GPT but not VMFS partition type):

At this stage, if I boot the ESXi from the USB, it is possible to format the partition with VMFS5:

And in vSphere client I can see the new datastore:

However there is an  issue with this approach – if I try to update ESXi (no matter which method), the installer will try to create and mount mpx.vmhba32:C0:T0:L0:2. This will fail with error like this:

vmkfstools failed with message: create fs deviceName : ‘/vmfs/devices/disks/mpx.vmhba32:C0:T0:L0:2′, fsShortName:’vfat’, fsName: ‘(null)’

deviceFullPath:/dev/disks/mpx.vmhba32:C0:T0:L0:2 deviceFile:mpx.vmhba32:C0:T0:L0:2

Error: Invalid argument

The workaround is to change the partition number from 2 to some other digit. Again I’m using Ubuntu for this. Export the partition table:

Edit the esxi2.txt (note to use use an editor which doesn’t create CRs at EOL):

label: gpt

label-id: 894975A7-EE02-4705-B962-F1AC4F0960FA

device: /dev/sdb

unit: sectors

first-lba: 34

last-lba: 30277598

/dev/sdb1 : start= 64, size= 8128, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=D6F99D1D-ED96-4416-BAB2-FA203D263CAF

/dev/sdb2 : start= 13500416, size= 16775168, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=50D5FE33-CDC7-413B-AF11-C32BF433AA85

/dev/sdb5 : start= 8224, size= 511968, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=F384F84D-D9CD-4872-B341-0F366160F507

/dev/sdb6 : start= 520224, size= 511968, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=61D5F035-849D-4D32-BA33-956EA4D3CC3B

/dev/sdb7 : start= 1032224, size= 225248, type=9D275380-40AD-11DB-BF97-000C2911D1B8, uuid=7793DABC-271C-4D00-BEBB-5838AF27665F

/dev/sdb8 : start= 1257504, size= 585696, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=0958745C-BEA6-4D4F-A7BA-E79244553D47

/dev/sdb9 : start= 1843200, size= 5242880, type=9D275380-40AD-11DB-BF97-000C2911D1B8, uuid=6BB6523C-2589-4D80-BB38-4F89B9B0AF1E

Change it like that:

label: gpt

label-id: 894975A7-EE02-4705-B962-F1AC4F0960FA

device: /dev/sdb

unit: sectors

first-lba: 34

last-lba: 30277598

/dev/sdb1 : start= 64, size= 8128, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=D6F99D1D-ED96-4416-BAB2-FA203D263CAF

/dev/sdb5 : start= 8224, size= 511968, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=F384F84D-D9CD-4872-B341-0F366160F507

/dev/sdb6 : start= 520224, size= 511968, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=61D5F035-849D-4D32-BA33-956EA4D3CC3B

/dev/sdb7 : start= 1032224, size= 225248, type=9D275380-40AD-11DB-BF97-000C2911D1B8, uuid=7793DABC-271C-4D00-BEBB-5838AF27665F

/dev/sdb8 : start= 1257504, size= 585696, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=0958745C-BEA6-4D4F-A7BA-E79244553D47

/dev/sdb9 : start= 1843200, size= 5242880, type=9D275380-40AD-11DB-BF97-000C2911D1B8, uuid=6BB6523C-2589-4D80-BB38-4F89B9B0AF1E

/dev/sdb10 : start= 13500416, size= 16775168, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=50D5FE33-CDC7-413B-AF11-C32BF433AA85

Write back the changed Partition Table:

Insert the USB back into the ESXi host, boot it up and check the partitions from within ESXi:

Verify partition 10 is visible and then format it:

Configure scratch partition to point to the new USB VMFS volume and enjoy 🙂