There is a pretty neat tool called ovftool that makes it easy to deploy an OVA/OVF from any source or extract the contents of an OVA. Ordinarily people would run it on their own machines but it is possible to run it on an ESXi host as well as per these articles: http://www.virtuallyghetto.com/2012/05/how-to-deploy-ovfova-in-esxi-shell.html, https://gist.github.com/ruzickap/fda71997083a41b0c6cd. However, if you tried that and tried to deploy the OVA on another vCenter from an ESXi machine you would have ran into a similar error as per this fictional example:
[root@foo:~] /vmfs/volumes/bar/OVFTool/vmware-ovftool/ovftool /vmfs/volumes/bar/qux.ova vi://foo:bar@baz.local/ Opening OVA source: /vmfs/volumes/ ... The manifest validates ... Error: Internal error: Failed to connect to server Completed with errors
This happens because the vi:// protocol by default uses port 443 (a.k.a. HTTPS) and that is usually blocked on the ESXi side. To rectify this issue, you will have to click on your host and go here through the vSphere client:
And check this box, and click ok:
Then it should work. Try again to run the same command. Do not forget to uncheck this box when you are finished with your deployment because obviously you do not want to open ports on your precious ESXi hosts which are not used. Alternatively, you could SSH to the host and run these commands:
esxcli network firewall ruleset set --ruleset-id esxupdate --enable true
To enable port 443 which is needed for this operation. And to disable after you are done:
esxcli network firewall ruleset set --ruleset-id esxupdate --enable false
If the ruleset with name “esxupdate” does not exist then you could create your own for the 443 port and then obviously change the name “esxupdate” to your own in these examples and pictures.
EDIT: However, nowadays it might not be the best decision to run ovftool directly on ESXi hosts. Check this article out. I recommend you to move your pipe-line over to Terraform for this use-case.