Try to make a clone of the VM and select the shared datastore as traget storage.
Clones fail, around 60-70% complete, same place the migrate fails.
Backups fail, disk will not copy or move.
Have you looked at the vmware.log file in the VMs home folder on the datastore? Any useful info/errors in there?
One option is you could potentially clone it as a workaround.
Try V2V migration using VMware Converter.
Nothing I can use.
MigrateESXVmkEventHandler: migration not in progress, not handling message 6.
2017-06-20T16:05:44.960Z| vmx| I120: Migrate: Overriding message callbacks with migration handlers.
Hmm nothing else? Are you able to post up the log or an extract? Anything useful in vmkernel.log?
What are you using for backup? Are there any orphaned snapshots? You can verify from the name of the vmdk.
Are you able to restart the host?
The only other thing I can think of is increasing the timeout but I suspect it may not help...
It is possible that there were some orphaned snaps
there was nothing to consolidate.
Sometime in the distant past (in a galaxy far) one server crashed and was rebuilt
all the VMware files had been and were on local datastores (bad)
then a long time passes, and I am hired.
Now time to fix this, so I setup a shared storage, fix another dead drive on the server
and successfully move 6 other servers to shared storage, but not this one.
did find a _1-000003.vmdk and a _1-00004.vmdk from back in 2015 17.4MB but Provisioned size 262GB
after several attempts did remove them from the folder (now stored separately)
The server is now running without them in the folder
so since I couldn't move the entire thing
used advance options and started with the second drive.
So then moved the server info - again success
then attempted drive c:\ . - Failed.
Yes Server is shutdown
So server log/ nvrma/ /vswp/ in shared storage - check
Drive 2 (with DB) in shared storage - check
Server running - check
Drive 1 - still in old location, without suspect files
Time on This Job - Three months.
If the snapshot disks are not attach to the VM, it is not a matter of concern. I would suggest you to try VMware standalone converter to perform a V2V
migration of the VM where traget VM datastore will be your shared datastore.
There might be a lock on the disk somehow. Next time you shutdown this vm I'd try the vmfsfilelockinfo: Finding the lock owners of a VMDK or file on a VMFS datastore in VMware ESXi 5.5 P05 and later (2110152) | VMware KB
That way you'll find out if there is something else accessing the disk and making it impossible to move.
In the Image we can see that the highlighted number is MAC of vmnic0 of esxi host and its holding the lock on w10-base-01a-flat.vmdk.
vmkfstools -D command can also be used to identify MAC address of esxi host holding the lock on the VM file.
Out put of the file is suppose to show the MAC address of the esxi host where the VM is currently running if it show any other host while VM is running or
If the output of the command show MAC address when the VM is powered off its a issue and you might need to flip the NIC or reboot the esxi host to
release the lock on the VM file/files.
My server Nic MAC information was already moved to new storage, and is running fine. The NIC is not locked to the host.
Think I mentioned that the Server Vol Info /vswp/ nram/ and disk 2 moved successfully
There are only two remaining files, but that is just because the server had to be started and is running.
Using the disk that remains in the old folder
attempted to install VMware convertor, and getting error on that, but that is another topic.
Yes. if only I had the root and password of the esxi host from the admin who left a long time before I was hired.
So far we have not located the password or guessed it.,
so I can not SSH or SFTP into the host
Placing the host in maintenance mode will not help either since it cant move the vdmk off the local storage it will just become unavailable.