Hi all,
I was wondering whether anyone had come across a odd issue we currently have. We have a 10 host cluster but currently we're unable to vmotion any running machines off one particular host to other hosts within the cluster. vmotion works ok between all the other hosts, plus we're able to vmotion a vm to the host experiencing issues, but are then unable to vmotion that same vm back to the host that we have just vmotioned it from.
Networking configuration looks the same, storage configuration looks the same, other hosts have plenty of capacity to accept the vm's (on the host are a variety of different size configurations, ranging from 1gb to 16gb of configured memory and 1 cpu to 4 cpu configured.
Message returned is:
failed to receive migration. Insufficient video ram. The maximum resolution of the virtual machine will be limited to 1672x1254. To use the configured maximum resolution of 2560x1600, increase the amount of video ram allocated to this virtual machine by setting svga.vramSize="16384000" in the virtual machine's configuration file. So this message leads me to this posts like the following:
However the VM's don't have any issue powering on, can be migrated between all other hosts without issue, can be migrated onto the host experiencing the problem but then can't be migrated back off without producing the above error. The VM's can be migrated off the host experiencing the issue if they are powered off or in a suspended state, they just can't be migrated off that same host if in a powered on state.
Checking the hostd log just after the vmotion has failed, the messages contained in there are vmotionsrc, resolvecb failed with fault: (vmodl.fault.systemerror), faultCause = (vmodl.MethodFault) null, reason = "Source detected that destination failed to resume".
VMkpings from the host experiencing the issue out to the other hosts, plus vmpkings from other hosts into the host experiencing the issue return successfully. We've also tried amended the migrate.enabled parameter to 0 and back to 1 again to see if that helps but with no joy.
The last resort is to power down all the VM's on the host, give the host a reboot and see how it the issue still persists after that, however there are a few VM's on the host where we'll have to get the downtime arranged before we can do that, so it'd be good to work out how to get these VMs off that host whilst they are still powered on, just in case we have this issue again.
Does anyone have any ideas / different logs to check to track down the issue?
Thanks
Brad Luettke