WilliamLam.com

Search Results for: ovftool

Quick Tip - Encoding special characters for OVFTool on the command-line

by // 1 Comment

If you use strong and complex passwords that contain special characters (which you should), it can some times be challenging from an automation perspective on how to properly escape these characters, which can also depend on the scripting or programming language that you are using.

Today I learned about a nice little enhancement in OVFTool 4.4 or later, which makes it easy to handle complex passwords containing special characters by supporting URL encoding for these characters. This is also great for those writing automation scripts and not having to input the password interactively but can now be added to OVFTool command-line string.

[Read more...]

Quick Tip - How to deploy OVF/OVA to multiple networks using OVFTool?

by // Leave a Comment

For automation purposes, customers use the handy OVFTool, which is a multi-platform command-line utility for uploading or exporting OVF/OVA images. During an upload, users would typically specify the --network argument which will assign the desired vSphere Network to the deployed VM and if the VM included multiple network adapters, it would assign the same network which can then be modified during post-deployment.

What if you had a OVF/OVA that included multiple network adapters and you wanted a different network for each adapter? Luckily, this is also supported with OVFTool by using the --nic argument, which expects the network name as codified within the OVF/OVA to tell OVFTool which vSphere Network to assign. You can find OVF/OVA network name by simply running OVFTool command against the OVF/OVA without any arguments and you should see the name as shown in the screenshot below.


Note: The network name in the OVF/OVA MUST be unique to be able to assign different networks during upload.

[Read more...]

OVFTool 4.4.1 - Upload OVF/OVA from URL using upcoming "pull" mechanism

by // 12 Comments

I was helping a fellow colleague yesterday with an OVA question and I came to learn about an upcoming feature in the popular OVFTool utility that would allow for a new method of uploading a remote OVF/OVA to either a vCenter and/or ESXi endpoint.

Historically, when you upload an OVF/OVA whether that is stored locally or remotely from a URL, the data path will actually transfer through the system running the OVFTool between the source and destination, which is ultimately the ESXi host which performs the actual download. Although the OVF/OVA data is not actually stored on your local system, the traffic is proxied through your system and can add an unnecessary hop if the remote OVF/OVA URL can directly be accessed by ESXi host.

A new --pullUploadMode flag has been introduced in the latest OVFTool 4.4.1 release, which will allow ESXi host to directly download (pull) from the remote OVF/OVA URL, assuming it has connectivity. In addition to version of OVFTool, you will also need to have either ESXi 6.7 or 7.0 environment for this new feature to work.

Disclaimer: Although this feature is available in latest OVFTool release, it is still under development and should be considered a Beta feature in case folks are interested in trying it out.

Since the ESXi host is directly downloading from the remote source, there are two additional security verification that has already been implemented. The first is an additional vSphere Privilege called "Pull from URL" which is under the vApp section. Without this, you will get a permission denied error.


Secondly, in addition to specifying the new CLI option, you will also need to provide another flag called --sourceSSLThumbprint which should include the SHA1 hash of endpoint hosting the OVF/OVA. This is an additional verification to ensure the validity of the server hosting the OVF/OVA.

Here is an example of deploying my latest ESXi 7.0 Update 1 Virtual Appliance OVA which is remotely hosted. The quickest way to obtain the SHA1 thumbprint is simply opening browser to based URL which is https://download3.vmware.com/


You will need to replace the space with ":" (colon), so the final string should look like BA:C6:4E:D9:AD:D4:53:B5:86:5A:5D:70:36:CF:89:93:D1:6C:F9:63

Note: The SHA1 thumbprint example shown above is only valid as of Oct 2020, as TLS certificates are replaced periodically, the SHA1 hash will change.

Here is an example OVFTool command to deploy from the remote URL

ovftool \
--X:logFile="ovftool.log" \
--acceptAllEulas \
--allowAllExtraConfig \
--allowExtraConfig \
--noSSLVerify \
--sourceSSLThumbprint="B2:52:9E:4D:57:9F:EA:53:4D:A0:0B:7F:D4:7E:55:91:56:C0:64:BB" \
--name="Nested-ESXi-7.0-Update-1-Appliance" \
--datastore=sm-vsanDatastore \
--net:"VM Network"="VM Network" \
--pullUploadMode \
https://download3.vmware.com/software/vmw-tools/nested-esxi/Nested_ESXi7.0u1_Appliance_Template_v1.ova \
'vi://*protected email*:[email protected]/Primp-Datacenter/host/Supermicro-Cluster'

If we switch over to the vSphere UI, we should see a new task called "Download remote files" which indicates the new pull method is being leveraged. One thing to note is that because ESXi is now performing the download directly, progress may not be known by the OVFTool client, since it is not longer the source for the data transfer. Another thing to be aware of is that OVFTool itself has built-in retry logic in case there is a slight interruption during the data transfer with the current mechanisms. In the "pull" scenario, there is no retry by ESXi and so depending on connectivity, its possible deployments can fail and complete re-transfer would be required.