I recently came across an interesting error when trying to deploy an OVF template in my lab. When I attempted to deploy the OVF I was surprised with a rather generic “Execution aborted” error:
With little to go on I decided to look at the vCenter logs. However, when I attempted to connect to the console of my vCenter Server Appliance (VCSA) I ran into a “… MKS: Failed …” error:
The “… MKS: Failed …” error is something that I am familiar with, and from experience I know this typically points to a hostname resolution problem (see http://kb.vmware.com/kb/749640). Sure enough, after a quick bit of investigation I confirmed that I did have a resolution issue. The desktop where I was running the vSphere client was on the corporate network and not able to resolve the hostnames for the lab systems I was trying to manage.
This created an interesting situation. Obviously, adding my lab systems to the corporate DNS was not an option. One possible solution would have been to RDP to a windows host inside my lab and run the vSphere client from there, but I didn’t want the overhead of using RDP. In the end I elected to just add some static host entries to my local “C:WindowsSystem32driversetchosts”.
Sure enough, once I worked around the hostname resolution issue I was not only able to connect to the VCSA console but I was also able to successfully deploy the OVF template.
It would have been nice to get a more descriptive error when deploying the OVF template, but fortunately I stumbled onto the “… MKS: Failed …” error that led me to the solution. In the future if I ever encounter problems when deploying OVF templates, I’ll be sure to verify the hostname resolution.
