I have see some VMware admins, that do a un-register / register of VM's if a host fails, and HA is not used, or for some reason fails. I have also see VMware admins remove ESXi hosts from the cluster to get the VM's un-registered.
The problem with this method is that the VM will get a new moref, and the moref is used for identifying the VM by many different types of software, that communicates with vCenter, for example backup software, management software, VDI solutions and other.
An example is Veeam Backup & Repliaction, this uses the moref to identify the VM that is in the backup/replication job and repository, so if you do er un-register / register, Veeam ses this as an new VM, af creates a new backup of vm that will take up extra space your backup repository.or no backup, depending on the job configuraion, or the job will fail,
This method also preserves Tags and Custom Attributes.
Here is an example of VM that was un-registered / registered.
Before it had moref "vm-40":
After un-registered / registered it has moref "vm41".
The solution is to not do a un-register, or remove ESXi host for cluster, but to register the VM's to another host.
Here is a VM, that was on a failed host.
If you try to do this i vCenter this will fail.
Error from re-register in vCenter.
But if you do the re-register directly on another host in the same datacenter, it will work.
Here I have logged in to another host i the same cluster, and found the VMX file, and then register the VM.
This is the result in vCenter.
And now I can "Power on" the VM.
If we check the moref it's still the same.
vCenter see the VM again an checks different things on the VM, and sees that it's the same VM, and reuses the same database object, this is also what happens during a HA failover. So we can say that what I just did was a manual HA failover.
VMX file locked
if you see this when after trying to register the VM, the VMX file is locked, and the VM is running on a another host. so you have to find out where is running.