VMware Cloud Community
dagn46
Contributor
Contributor

Vcenter 4.1: Vmotion problem: "The VM failed to resume on the destination during early power on"

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

0 Kudos
7 Replies
marcelo_soares
Champion
Champion

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.

Marcelo Soares
0 Kudos
dagn46
Contributor
Contributor

thanks for the answer Smiley Happy

it doesn't work for all VMs Smiley Sad ...

0 Kudos
marcelo_soares
Champion
Champion

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.

Marcelo Soares
0 Kudos
enicon
Contributor
Contributor

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

0 Kudos
raadek
Enthusiast
Enthusiast

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

0 Kudos
Vnice
Contributor
Contributor

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.

0 Kudos
bstampfle
Contributor
Contributor

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.

0 Kudos