During the install of FreeNAS, the process may hang with the following errors:

This was with both FreeNAS-9.10.1-U2 and FreeNAS-9.10.2-U1 (though it is unlikely that this specific incompatibility is isolated to only these two builds). One thing to try is to first shut down the guest and then reconfigure the VM. For the Hard Disk configuration options of the VM, the default setting for Virtual Device Node is SCSI Controller. Changing it to SATA Controller resolved the error and FreeNAS was able to then install successfully.

I ran into a situation where the host had crashed because of a driver problem (vmw_ahci). After changing the driver and rebooting the host, one of the guest VMs then failed to power on with the following errors:

• File system specific implementation of LookupAndOpen[file] failed
• Object type requires hosted I/O
• Cannot open the disk ‘…vmdk’ or one of the snapshot disks it depends on.
• Module ‘Disk’ power on failed.
• Failed to start the virtual machine.

The solution was to repair the disk using vmkfstools. This particular VM was split into two files, vmname.vmdk and vmname-s001.vmdk. You will want to perform the commands on the primary (pointer) vmdk (not vmname-s###.vmdk).
From the ESXi console, issue the following command substituting your actual path:

In this case vmkfstools reported that the disk should be repaired. It would be prudent at this point to back up your vmdk files before trying the repair. Then initiate the repair on the primary vmdk with:

Once you get a notification that the repair has completed, try to start your VM again.

Upgrading from ESXi 5.5 to 6.5, performance of the host was relatively poor on a JetWay JNF9G-QM77. Guests were extremely sluggish.

There were also several errors  tracked in the various logs related to the boot drive and the datastore associated with the boot drive.

In the vobd log:

In the vmkwarning log:

In the vmauthd log:

The solution was to disable the new AHCI driver of ESXi 6.5 (vmw_ahci). From the ESXi console issue the following command:

Then after a reboot ESXi should be using the sata–ahci driver. You can confirm this by checking the list of storage adapters for the host, looking for one titled Panther Point AHCI Controller.
After this driver swap, performance of the host should be restored.

If you are having trouble getting ESXi to discover a Synology iSCSI target with CHAP authentication, check your vobd log for errors that may look similar to the below:

This basically confirms some kind of problem negotiating the CHAP authentication. After double checking that you are using the correct CHAP credentials and you are still not able to get the ESXi host to discover the Synology target, try the steps below:

1. In the Synology Storage Manager for iSCSI Target, first disable Mutual CHAP (if enabled) and check that CHAP is enabled.
   Then in ESXi Configure iSCSI as follows:
2. Set only a Dynamic Target using the IP address and port of the Synology target. Remove any Static Target that you may have set.
3. Temporarily set CHAP Authentication to “Do not use CHAP”
4. Set Mutual CHAP Authentication to “Do not use CHAP”
5. Click Save Configuration
6. Click Refresh on the Devices tab and confirm the Synology is not being discovered
7. Now go back the iSCSI configuration in ESXi
8. Set CHAP Authentication back to “Use CHAP”
9. Click the down arrow and enter your CHAP credentials
10. Confirm the Static Target is now populated with the Synology target address information. If not, try populating it now.
11. Click Save Configuration
12. Click Refresh on the Devices tab

The Synology target should then show up in ESXi.