WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

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

10.14.2020 by William Lam // 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.

Categories // Automation, OVFTool, vSphere 6.7, vSphere 7.0 Tags // ovftool, vSphere 6.7, vSphere 7.0

Update on ESXi on Apple Mac Mini 2018 & Mac Pro 2019

02.28.2020 by William Lam // 80 Comments

Although there has not been any news in some time regarding the support for ESXi on the latest Apple Mac Mini 2018 and the recently released Apple Mac Pro 2019, there has definitely been work happening behind the scenes at VMware. Today, I would like to share a pretty significant update as a result of some of these efforts.

MacOS Guest

One of the biggest issue which I had observed when using a T2-based Apple system with ESXi is that it would fail to boot a MacOS Guest and just keep rebooting the VM. I am very happy to announce that this issue has been resolved and ESXi can now properly recognize the Apple System Management Controller (SMC) device which is used as part of the MacOS Guest start up process. This now means a MacOS Guest will be able to properly boot on a T2-based Apple system.

Thunderbolt 3

Another impact of a T2-based Apple system with ESXi is that storage and networking devices connected to the Thunderbolt 3 ports are not visible. I am also happy to announce that this issue has been resolved and ESXi can now see PCIe devices that are attached to the Thunderbolt 3 ports.

An ESXi Advanced Setting change is required for Thunderbolt 3 to work correctly and the following command will need to be executed after installing ESXi:

esxcli system settings kernel set -s pciExperimentalFlags -v 16

Once the setting has been applied, a system reboot will be required and your PCIe devices will show up properly. In future, this additional configuration may not be required and can be detected based on the underlying hardware.

Both of the fixes mentioned above are included in the latest ESXi 6.7 Patch 02 (ESXi670-202004002) release which is available today! Hopefully this was the news that many of you have been waiting for 😀

UPDATE (09/02/21) - Per this official blog post, VMware will no longer pursue hardware certification for the Apple 2019 Mac Pro 7,1 for ESXi.

UPDATE (02/23/21) - The Community NVMe Driver for ESXi Fling now enables access to the local Apple NVMe device.

UPDATE (08/27/20) - The Apple 2018 Mac Mini 8,1 is now officially supported with ESXi 6.7 Update 3 which requires the latest ESXi 6.7 Patch 03 which also incorporates automatically setting the ESXi Advanced Setting for Thunderbolt 3 access.

UPDATE (06/25/20) - The Apple 2018 Mac Mini 8,1 is now officially on the VMware HCL and is fully supported with ESXi 7.0b, which contains the fixes mentioned above. See note below on 06/23 for more information.

UPDATE (06/23/20) - ESXi 7.0b has just been released and contains fixes for both the MacOS guest boot issue support for Thunderbolt 3 devices which now enables support for the vSphere 7 release. One additional enhancement, customers no longer need to configure the ESXi Advanced Setting to enable Thunderbolt 3 support, this is now automatically configured based on detecting an Apple hardware system such as an Apple Mac Mini 2018 or Apple Mac Pro 2019. This is a patch release and you will need to go to the VMware Patch Portal site to download and apply the update.

Now, before you rush out to start deploying MacOS Guests on either the Mac Mini or Mac Pro, I do have to mention that neither the Mac Mini 2018 or the Mac Pro 2019 will be officially supported by VMware. Due to the current situation that we are all in with COVID-19, personnel access to VMware facilities like many other organizations has been severely restricted and/or prohibited. In fact, much of the early validation was done by yours truly using a Mac Mini 2018 which I had access to (Thanks Michael Roy) as Engineering did not have access to hardware during the shelter in place orders. This also means that certifications of these platforms is still on-going and until these systems are officially listed on VMware's HCL, they will not be officially supported by VMware.

Disclaimer: VMware currently does not officially support the Apple 2019 Mac Pro7,1

[Read more...]

Categories // Apple, ESXi, vSphere 6.7 Tags // apple, ESXi 6.7, mac mini, mac pro

Apple Mac Mini on VMware HCL!

08.01.2019 by William Lam // 15 Comments

For the past 6 years, the Apple Mac Mini has been one of the most popular hardware platforms for Virtualizing MacOS running on VMware vSphere enabling our customers to develop and build iOS and MacOS applications. With that said, VMware has historically only supported two Apple hardware platforms: Xserve (now EOL'd) and the Mac Pro (6,1) which is officially listed on VMware's Hardware Compatibility list and this has been officially supported by VMware since 2012 when we first introduced support for MacOS Virtualization with the vSphere 5.0 release.

As many of you know, I have been a huge advocate of this platform for a number of years now and I have been working with various Engineers over the years to ensure that we have the exact same user experience when working with ESXi on the Mac Mini as you do with the Mac Pro. I still recall in the early days where it took several "hacks" to get ESXi to successfully boot and install.

Today, ESXi installs on the Mac Mini just like any other x86 platform. It runs amazing well for our customers, especially for a consumer device, who have deployed them in their datacenters ranging from a couple hundred to several thousands for some of our larger Enterprise customers, one such example is MacStadium, the largest Apple Infrastructure-as-a-service provider which many of the Fortune 100/500 companies are leveraging to provide them with a platform to build and develop for the Apple eco-system.

UPDATE (08/27/20) - Apple 2018 Mac Mini 8,1 has been added to VMware HCL which supports both ESXi 6.7 Update 3 (Patch 03) & ESXi 7.0b

[Read more...]

Categories // Apple, ESXi, vSphere 6.7 Tags // apple, ESXi, ESXi 6.7 Update 2, mac mini, vSphere 6.7 Update 2

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • …
  • 11
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...