Chances are if you are in IT management or providing IT services you have had to deal with virtualization hosts. When it comes time to retire your old hardware and move to a new host, there are a number of different ways to go about it. One in particular for ESXi lets you avoid most incompatibility issues, transfer in the thin format, and go directly from host to host through the shell without needing a vCenter server. That is using VMware’s OVF Tool.
Thankfully, there are some great guides on getting the software up and running and starting your transfers. While you could install the tool on a third machine and use it to initiate the transfers across the hosts, running the tool directly from the hosts can make certain situations a little easier, like transferring the VMs from an area with restricted access. While setting up and using the tool is well documented, there are a few issues you may run into and a first time user may get overwhelmed and give up on using this great tool.
The first issue you may run into after copying the OVF Tool files to your ESXi Host is when you try to run a test on the program. The issue occurs based on the version of the OVF Tool that you are using and the version of your ESXi server. When setting up the latest tool on ESXi 5.5, you need to create a symbolic link in your /usr/lib directory pointing to the tools install location. A guide to this is written in the comments here. While that will work on the latest version of the tool with ESXi 5.5, you may have other library file errors when using an older version of ESXi.
The latest tool does have issues when installed onto ESXi 5.0. Hopefully, if you are switching to a new server you have the latest version of ESXi installed and can just place the tool on your destination server and can send the command from there. Otherwise, you may need to look for an older version of the OVF Tool that properly supports your version.
The second problem may occur — but does not for all users — if you do not specify a username and password in the OVF Tool command: /usr/lib/vmware-ovftool/ovftool vi://<username>:<password>@<host>/<file> vi://<username>:<password>@host. You may get hit with a screen of asterisks that will require you cancel the process. This does not seem to be consistent across versions but may occur.
Another issue occurs with the transfer command itself. While not a big deal initially, it may create extra work for you later if you specifically needed to keep a thin client disk thin. The default setting with OVF Tool is to transfer the file in the thick format regardless of your current disk type. While the guide does not mention that specifically it does show the “-dm=thin” command in one of its screenshots. If you miss this tag, the tool will still finish, but you will need to convert the VM back to a thin provision if that is what you needed taking more time.
The least visible issue occurs while using the tool. When attempting to use this tool you may see the error message “Failed to deploy OVF package: The task was canceled by a user.” This message can have a number of causes, one of which being the decision to cancel the process. A more common reason for this to occur is that a physical device or stored data on your host is set as a device on your VM. This could be the physical optical drive loading an iso from the datastore to the VM or even a USB drive attached as a quick data dump. Since this device is physically attached or stored on the current host, OVF Tool will throw an error and cancel the process.
With the optical drive, the fix for this is as easy as changing the drive to use the “Host Device” instead of a “Datastore ISO File.” For other devices, just removing and reattaching would be the easiest way to go. The good news is that this will trigger early on and let you know there is an issue. An OVF export by itself does not receive this error until the import occurs, and you would need to modify the files manually with a text editor to get it working again. By running the process with the OVF Tool, the hosts do an import and export at the same time and an error on the import will cancel the whole process.
Obviously, there are possibilities of other errors occurring while using this process, but most can be tested before going live to avoid major issues. Thankfully, between guides, kb articles, comments, and the VMware community, you can usually find an answer to any issues you are facing.