Hi all,
I can't Vmotion VMs: it fails at 10 % with this popup: "The VM failed to resume on the destination during early power on."
I did on the CLI:
+ /etc/init.d/mgmt-vmware restart
+ /etc/init.d/vmware-vpxa restart
+ reconfigure for HA
My VMware: Vcenter 4.1 & ESX 4.0
Thanks for your help
Regards
Try to vmotion with Low priority. Also, go to edit settings of the VM and change the swap location to the VM directory (it should be "default", but change it anyway).
Marcelo Soares
VMWare Certified Professional 310/410
Virtualization Tech Master
Globant Argentina
Consider awarding points for "helpful" and/or "correct" answers.
thanks for the answer
it doesn't work for all VMs ...
I had it also... really annoying... you can try restarting the management agents on the source and destination hosts. This sometimes works...
Marcelo Soares
VMWare Certified Professional 310/410
Virtualization Tech Master
Globant Argentina
Consider awarding points for "helpful" and/or "correct" answers.
Hi,
it happened to me also, and I found the problem was the working directory. For some reason the machine was in a directory which name ended with a space, such as "virtual machine ": in the .vmw the parameter was written without the final " ". I believe this may have happened after a storage vmotion and a rename of the machine, or for a trunkation of the vm name in the generation of the directory's name during the storage vmotion. My vm's name is very long and it doesn't actually end with a " ", but it contains a couple of spaces. I believe the name was trunkated at a certain point to generate the working directory name and by chance the last character was a space, but for some bug the trailing " " was cut out of the workingdirectory parameter in the .vmx
Hi,
I have bumped into the same issue & found this useful:
http://www.vmadmin.info/2010/09/esxi-vmotion-fails-10.html
I am using NetApp filer as well & two VMkernel ports - turned out only one of them had root access to the NFS volume hosting VMDK file; adding the second one solved the issue.
Regards,
Radek
I had this same issue in my lab today. I saw many "Permission denied" log messages in the /var/log/messages file on the Vmotion destination host:
Jan 25 15:22:15 vmkernel: 0:19:32:38.993 cpu23:173966)WARNING: NFSLock: 2026: Failed to create .lck-e9b7200000000000 : Permission denied
Jan 25 15:22:15 vmkernel: 0:19:32:38.993 cpu23:173966)NFSLock: 2819: failed to get lock on file vmware-14.log 0x410003e34c10 on 10.8.129.132 (10.8.129.132): Permission denied
I'm not sure I fully understand what these mean but I did notice that I could vmotion the VM to any other host except a specific one. To recover I moved all other VMs off the problem destination host and rebooted it. Subsequently this cleared the "lock" on the host and then I was able to vmotion the VM to it.
The previous day I had tried a host+storage vmotion from the same source and destination hosts. This did not go well, the transfer got stuck and never completed. I believe that this was root cause of the issue.
Confirmed that I have ran in to the same problem and it was because the NAS team did NOT apply 'root' permissions to the volume in the exports file.