2019-12-12T16:02:09.743Z warning hostd[1B4C2B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/-db5986e0-695f-/x/x.vmx] Snapshot create succeeded, but UID 650 not in list.
2019-12-12T16:02:09.743Z warning hostd[1B4C2B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/-db5986e0-695f-/x/x.vmx] Failed operation
2019-12-12T16:02:09.744Z info hostd[1B4C2B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/-db5986e0-695f-/x/x.vmx] State Transition (VM_STATE_CREATE_SNAPSHOT -> VM_STATE_ON)
2019-12-12T16:02:09.744Z info hostd[1B4C2B70] [Originator@6876 sub=Vimsvc.TaskManager] Task Completed : haTask-49-vim.VirtualMachine.createSnapshot-127313764 Status error
2019-12-12T16:02:09.595Z warning hostd[1B4C2B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/-db5986e0-695f-/x/x.vmx] UpdateStorageAccessibilityStatusInt: The datastore is not accessible ide1:0.fileName = "/vmfs/volumes/-4df76266-7681-/contentlib--0b4f-4c5b-bc5b-/-4f37-47e9-aa1e-/x.iso"
While virtual machines consist of multiple files, the ESXi host service (hostd) treats them as a single object. If any of the VMs are inaccessible, the virtual machine will be transitioned to an invalid load state.
For example, if an ISO has been attached to the VM and that ISO was moved away from the datastore; or was deleted without removing it from the virtual machine beforehand, the virtual machine will experience the issues described.
Furthermore, when the datastore that the VM is located on becomes inaccessible, hostd will not refresh the disk. Default entries with 0 capacity will be generated for those virtual disks that were not yet cached. In this situation, hostd will not refresh the snapshot list for the VM. As a result, snapshot creation tasks will fail. The snapshot itself is actually getting created, but the system fails to find the new UUID in the list, resulting in the task failing.
$ vim-cmd vmsvc/getallvms | grep <VM_name>
$ vim-cmd vmsvc/reload <VMID>