Let me start by saying that VMWare does not officially support this and as far as I can tell they don’t necessarily want you to do it. So don’t expect to get support from them on this. However, with the fact that vSphere 6.5 is now old news chances are if you are here that doesn’t bother you. If it does then don’t do this. For me this made sense because I have machines that boot off ESXi from a USB and I wanted to be able to store ISOs and other files in a datastore that would follow the boot usb not the internal datastore. I also wanted to have those items separate from the datastore I use for VMs without giving up internal space.
In terms of the actual procedure it is pretty simple. We will remote into the host with SSH, add a new partition and then make it a datastore. That’s it. Once you do that it shows up in the GUI and you can interact with it like an other datastore.
Important Notes: There are a few things you need to know about this procedure and the datastore it procedures. First, if you delete the datastore it also delete the partition and you have to go through all these steps again. As far as I can tell there doesn’t seem to be any lasting affects, but just something you should know.
create outthen creating our datastore. It is also important to note that this is for ESXi. The original instructions I found were for ESXi 6.7 so several of the steps didn’t work for me and I had to come up with my own. Overall this is quick and painless so lets jump right in.
1. Go to the host you want to do this with and enabled SSH
2. SSH into the host
3. Now we need to get the lay of the land … well kinda … we need to find our USB and then get information about the partition map. So let’s first start by getting a list of drives and partitions by running the command “ls /dev/disks/”. Below is the output on a machine with no other datastore. If you have other datastore it will show those as well.
[root@localhost:~] ls /dev/disks/
mpx.vmhba32:C0:T0:L0
mpx[root@XserveTop:~] ls /dev/disks/
mpx.vmhba32:C0:T0:L0
mpx.vmhba32:C0:T0:L0:1
mpx.vmhba32:C0:T0:L0:5
mpx.vmhba32:C0:T0:L0:6
mpx.vmhba32:C0:T0:L0:7
mpx.vmhba32:C0:T0:L0:8
mpx.vmhba32:C0:T0:L0:9
naa.500039300001b4a4
naa.500039300001b4a4:1
naa.500a0751e1dd3c4f
naa.500a0751e1dd3c4f:1
naa.500a0751e1dd3c74
naa.500a0751e1dd3c74:1
naa.58889141003923aa
naa.58889141003923aa:1
t10.NVMe____Samsung_SSD_970_EVO_Plus_2TB____________E61B921158382500
t10.NVMe____Samsung_SSD_970_EVO_Plus_2TB____________E61B921158382500:1
vml.0000000000766d68626133323a303a30
vml.0000000000766d68626133323a303a30:1
vml.0000000000766d68626133323a303a30:5
vml.0000000000766d68626133323a303a30:6
vml.0000000000766d68626133323a303a30:7
vml.0000000000766d68626133323a303a30:8
vml.0000000000766d68626133323a303a30:9
vml.0100000000453631425f393231315f353833385f323530300053616d73756e
vml.0100000000453631425f393231315f353833385f323530300053616d73756e:1
vml.0200000000500039300001b4a4587365727665
vml.0200000000500039300001b4a4587365727665:1
vml.0200000000500a0751e1dd3c4f435431303030
vml.0200000000500a0751e1dd3c4f435431303030:1
vml.0200000000500a0751e1dd3c74435431303030
vml.0200000000500a0751e1dd3c74435431303030:1
vml.020000000058889141003923aa4f5743204d65
vml.020000000058889141003923aa4f5743204d65:1Here we are looking for the partition 1, 5, 6, 7, 8 and 9. If you look in the above list you will see the corresponds with “vml.0000000000766d68626133323a303a30”. That tells us that “/dev/disks/vml.0000000000766d68626133323a303a30” is our boot usb.
4. Now that we know the location of the boot usb we can take the next step and get more information on the partition map for that specific disk. To do that we use “partedUtil getptbl /dev/disks/<DISK NAME>”:
[root@localhost:~] partedUtil getptbl /dev/disks/vml.0000000000766d68626133323a303a30
gpt
7800 255 63 125313283
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0This gives us some really valuable information. HOWEVER, you may get an error or warning. To fix it go to the bottom of this article to the Errors and Issues section. If you don’t see an error or warning just continue to the next step. Later we create our new partition table we will need to feed this information back in. The key things for us here are the various partitions.
5. Now we need to know what the last writeable block is. This is because for our new partition we need to say where it start and ends. To get this we run “partedUtil getUsableSectors /dev/disks/”. Your output should look like this:
[root@localhost:~] partedUtil getUsableSectors /dev/disks/vml.0000000000766d68626133323a303a30
34 125313249Here we get 2 numbers. The first usable in the first column and the last usable in the second column. We need these to define the new partition we are making. In this case we want it to start right after the last partition and run to the end of the unusable sectors. If you look at the output of “partedUtil getptbl /dev/disks/vml.0000000000766d68626133323a303a30” and go the last entry it gave us “9” you will see that that partition starts at “1843200” and ends at “7086079”. So we will add 1 to the ends and start our new partition there. so our new partition will run from 7086080 to 125313249.
7. At this point we now have what we need to create the new partition. To do this we will use the “setptbl” option. This is going to a long command, but don’t let it scare you. Most of this command is just feeding back what we already got out. It will take the format of “partedUtil setptbl /dev/disks/<DISK NAME> DiskLabel [“partNum startSector endSector type/guid attribute”]*”. As I mentioned before this will ALL come from what we already have. Here is what it will look like with new lines instead of spaces. You will have to change the newlines to spaces to use it, but this helps you see how it related to our output of “partedUtil getptbl /dev/disks/<DISK NAME>”:
partedUtil setptbl /dev/disks/vml.0000000000766d68626133323a303a30 gpt
"1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B 128"
"5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 0"
"6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 0"
"7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 0"
"8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 0"
"9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 0"
"2 7086080 125313249 AA31E02A400F11DB9590000C2911D1B8 0"Ok so hopefully this makes sense to you. The first lines are just a repeat of what we got from the output earlier and the last line is our new section that start 1 after the last and ends at the last usable sector. So here is what you will see when you run this in the terminal:
[root@XserveTop:~] partedUtil setptbl /dev/disks/vml.0000000000766d68626133323a303a30 gpt "1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B 128" "5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 0" "6 52022
4 1032191 EBD0A0A2B9E5443387C068B6B72699C7 0" "7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 0" "8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 0" "9 1843200 7086079 9D27538040AD11DBBF97000
C2911D1B8 0" "2 7086080 125313249 AA31E02A400F11DB9590000C2911D1B8 0"
gpt
0 0 0 0
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 0
2 7086080 125313249 AA31E02A400F11DB9590000C2911D1B8 08. Ok so now let’s take our new partition and make it into a Datastore! To do that we will use “vmkfstools -C vmfs6 -S <DATASTORE NAME> /dev/disks/<DISK NAME>:2”. Once you run this command you are stuck with the name so make sure you pick something you like! Here is an example of the output of this command:
[root@XserveTop:~] vmkfstools -C vmfs6 -S BootUSB /dev/disks/vml.0000000000766d68626133323a303a30:2
create fs deviceName:'/dev/disks/vml.0000000000766d68626133323a303a30:2', fsShortName:'vmfs6', fsName:'BootUSB'
deviceFullPath:/dev/disks/mpx.vmhba32:C0:T0:L0:2 deviceFile:mpx.vmhba32:C0:T0:L0:2
ATS on device /dev/disks/mpx.vmhba32:C0:T0:L0:2: not supported
.
Checking if remote hosts are using this device as a valid file system. This may take a few seconds...
Creating vmfs6 file system on "mpx.vmhba32:C0:T0:L0:2" with blockSize 1048576, unmapGranularity 1048576, unmapPriority default and volume label "BootUSB".9. This isn’t so much a step as it is checking your work! At this point as long as things went well you should see a new datastore on your ESXi host! HOWEVER, if you delete it you will have to go through all this again! ESXi will delete the datastore AND the partition so don’t expect to be able to just skip these steps!
Errors and Issues
When I first tried this procedure I got an error and warning notice that the disk needed to be fixed. This is what it looked like:
[root@localhost:~] partedUtil getptbl /dev/disks/vml.0000000000766d68626133323a303a30
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 back[root@XserveTop:~] partedUtil getptbl /dev/disks/vml.0000000000766d68626133323a303a30
gpt[root@XserveTop:~] partedUtil getptbl /dev/disks/vml.0000000000766d68626133323a3
03a30
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/mpx.vmhba32:C0:T0:L0 appears to be used, you can fix the GPT to use all of the space (an extra 109881945 blocks) or continue with the current setting? This will also move the backup table at the end if is is not at the end already. diskSize (125313283) AlternateLBA (15431337) LastUsableLBA (15431304) NewLastUsableLBA (125313249)
gpt
7800 255 63 125313283
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0I don’t know what caused this and really doesn’t matter. What does matter is getting it fixed. Just as the message says you can use the fix command like this “partedUtil fix /dev/disks/<DISK NAME>”. Here is what that looks in the terminal:
[root@XserveTop:~] partedUtil fix /dev/disks/vml.0000000000766d68626133323a303a3
0
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/mpx.vmhba32:C0:T0:L0 appears to be used, you can fix the GPT to use all of the space (an extra 109881945 blocks) or continue with the current setting? This will also move the backup table at the end if is is not at the end already. diskSize (125313283) AlternateLBA (15431337) LastUsableLBA (15431304) NewLastUsableLBA (125313249)
[root@XserveTop:~] partedUtil fix /dev/disks/vml.0000000000766d68626133323a303a3
0
[root@XserveTop:~] partedUtil getptbl /dev/disks/vml.0000000000766d68626133323a303a30
gpt
7800 255 63 125313283
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0As you can see I ran the command twice and then ran the original “getptbl” command just to make sure the error was gone. For me this solved the issue and I didn’t see the error again.