While attempting to add an existing VMFS datastore to a newly built ESXi host, the host wanted to reformat the datastore instead of detecting the existing signature.
It was found that accessing the esxcfg-volume command from the CLI was the method to use. After adding the storage back in via the UUID, it took about 10 seconds for it to show up in the VMware interface. The syntax below was used to correct the issue. As you can see, the command esxcfg-volume -m <UUID> was ultimately used to correct the issue.
~ # esxcfg-volume -l VMFS UUID/label: 54ee9d73-ccd2eba2-e4bb-c8600022a600/store1.storage1.destephen.local Can mount: Yes Can resignature: No (the volume is being actively used) Extent name: t10.945445000000000043877353032713030000000000000000:1 range: 0 - 1429503 (MB) ~ # esxcfg-volume esxcfg-volume <options> -l|--list List all volumes which have been detected as snapshots/replicas. -m|--mount <VMFS UUID|label> Mount a snapshot/replica volume, if its original copy is not online. -u|--umount <VMFS UUID|label> Umount a snapshot/replica volume. -r|--resignature <VMFS UUID|label> Resignature a snapshot/replica volume. -M|--persistent-mount <VMFS UUID|label> Mount a snapshot/replica volume persistently, if its original copy is not online. -U|--upgrade <VMFS UUID|label> Upgrade a VMFS3 volume to VMFS5. -h|--help Show this message. ~ # esxcfg-volume -m 54ee9d73-ccd2eba2-e4bb-c8600022a600 Mounting volume 54ee9d73-ccd2eba2-e4bb-c8600022a600 ~ #