When I try to migrate a VM it fails at 82% with an error "A general system error occurred: Source detected that destination failed to resume."
I have 32 bit VM running on ESX 4.0, and the host machines are 64 bit machines with Intel VT enabled.
I had tried all the trouble shooting methods given in
but nothing solved the issue at hand.
Did anybody face a similar issue ? ANy suggestions are welcome.
Check the vmkernel log file for any errors relating to the VMotion. Can you VMotion any virtual machines or do they all fail with that error?
Also, did you ensure that Intel VT is enabled in the BIOS on all servers? Even though it is a 32-bit server it might be detecting the difference and causing the VMotion to fail.
Do you have this problem with a VMotion or a Storage VMotion?
Cause your problem seems a SVMotion problem, like this:
I checked the vmkernel log and found this:
vmkernel: 0:01:34:10.039 cpu3:4309)WARNING: Migrate: 3267: 1254157851687500 😧 Migration considered a failure by the VMX. It is most likely a timeout, but check the VMX log for the true error.
but couldn't find the where VMX log is located ? Do you know where they are located?
Try checking the vmware.log for the VM that you're trying to migrate and see if you can get additional information in there.
I found the following messages, I think the destination host is unable to access the NFS Share where the VM is located.
what bothers is that I am able to do a cold migration i.e. power off VM and resume on a different but when I do a live migration it is giving me this error.
But even when I do a cold migration after powering on the VM it shoud stil use the same NFS Share to access the VM right ? Then why is the destination host giving an error during migration.
FILE: File_GetVMFSAttributes: could not open /vmfs/volumes/4e26a03c-4979fc77/win2k3-1/win2k3-1.vmdk.
Sep 28 11:42:10.305: vmx| FILE: File_GetVMFSfsType: File_GetVMFSAttributes failed
Sep 28 11:42:10.306: vmx| DISKLIB-DSCPTR: DescriptorDetermineType: failed to open '/vmfs/volumes/4e26a03c-4979fc77/win2k3-1/win2k3-1.vmdk': Could not find the file (63)
Sep 28 11:42:10.306: vmx| DISKLIB-LINK : "/vmfs/volumes/4e26a03c-4979fc77/win2k3-1/win2k3-1.vmdk" : failed to open (The system cannot find the file specified).
Sep 28 11:42:10.306: vmx| DISKLIB-CHAIN : "/vmfs/volumes/4e26a03c-4979fc77/win2k3-1/win2k3-1.vmdk" : failed to open (The system cannot find the file specified).
Sep 28 11:42:10.306: vmx| DISKLIB-LIB : Failed to open '/vmfs/volumes/4e26a03c-4979fc77/win2k3-1/win2k3-1.vmdk' with flags 0xa (The system cannot find the file specified).
Sep 28 11:42:10.307: vmx| Msg_Post: Error
Sep 28 11:42:10.307: vmx| http://msg.disk.fileNotFound VMware ESX cannot find the virtual disk "/vmfs/volumes/4e26a03c-4979fc77/win2k3-1/win2k3-1.vmdk". Please verify the path is valid and try again.
Sep 28 11:42:10.307: vmx| http://msg.disk.noBackEnd Cannot open the disk '/vmfs/volumes/4e26a03c-4979fc77/win2k3-1/win2k3-1.vmdk' or one of the snapshot disks it depends on.
Sep 28 11:42:10.307: vmx| http://msg.disk.configureDiskError Reason: The system cannot find the file specified.----
Sep 28 11:42:10.313: vmx| Module DiskEarly power on failed.
Sep 28 11:42:10.314: vmx| VMX_PowerOn: ModuleTable_PowerOn = 0
Sep 28 11:42:10.314: vmx| MigrateSetStateFinished: type=2 new state=11
Sep 28 11:42:10.314: vmx| MigrateStateUpdate: Transitioning from state 10 to 11.
Sep 28 11:42:10.314: vmx| Migrate_SetFailure: VM failed to resume on destination during early power on.
Sep 28 11:42:10.315: vmx| Msg_Post: Error
Sep 28 11:42:10.315: vmx| http://msg.checkpoint.resume.fail VM failed to resume on destination during early power on.
Sep 28 11:42:10.315: vmx| -
Everything is working now, I am not sure why ?
I did the following
1) rebooted the whole setup (esx hosts & Vcenter server machines)
2) reconfigured the VMkernel port
3) reconfigured the NFS Share (I think this is the step which made everything work) .
The reason it started working for you again was your reconfiguration of the NFS share as seen from the ESX hosts. VMware generates a hexadecimal volume id based on the name you used for the share mapping. If you didn't type exactly the same across all your hosts, the volume id will be different and you'll get this problem.