WilliamLam.com

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.

Instant Clone Apple MacOS

by // 1 Comment

Whether you are a brand new startup working on the next hot mobile app or an established Enterprise or Consumer brand company, development and testing of Apple iOS and/or MacOS is simply a reality in todays world. The vast majority of these customers accomplish this by running Apple MacOS on vSphere, either within their own on-premises datacenter or leveraging MacStadium, the largest MacOS Cloud hosting provider, who also runs their Mac infrastructure using VMware vSphere.

The ability to quickly build/test and deploy your application (Continuous Integration and Continuous Delivery) can mean the difference of having an edge over you competitor or being able to keep up with the demands of your business. Many customers have benefited from using vSphere platform and with technologies like Linked Clones, which allows you to quickly spin up a new VM without having to perform a complete full clone, it means you can build and test your application even faster.

In vSphere 6.7, we introduced a major enhancement to Instant Clone, which you can read more about here and here. One of the questions I have been seeing lately is whether Instant Clone can be applied to MacOS guests? The answer is absolutely! In fact, Matt Moriarity, who works for TravisCI, recently shared some tidbits on how to get a MacOS Mojave guests to see the updated MAC Address to ensure that there are no network conflicts when performing an Instant Clone.

The majority of the "hard" work to use Instant Clone is really from within the GuestOS and the customization script that needs to be developed. In fact, Instant Clone is pretty OS agnostics and you can even Instant Clone Microsoft Windows 98 and 2000, if you really wanted to 😀

[Read more...]

Dynamic vSphere Health Checks in vSphere 6.7+

by // 14 Comments

One really neat feature of the vSphere HTML5 Client that was shipped in vSphere 6.7 is the ability to deliver new data applications that can run in the vSphere UI without requiring customers to update or upgrade their underlying vCenter Server. An example of this is the vSphere Health Check plugin that was included in vSphere 6.7, which I am guessing most folks probably did not even notice, including myself. The vSphere Health plugin is located at the vCenter Server level and under Monitor->Health as shown in the screenshot below.


Unlike a traditional vSphere Plugin, where the code and business logic is local to the vCenter Server and must be updated each time for new functionality, these data applications are actually delivered automatically and more importantly, out-of-band to a vCenter Server patch or upgrade. This means as new functionality is added, customers will automatically get the latest updates without having to do anything. So how does this actually work?

[Read more...]