virtuallyGhetto

vSphere 6.7

Quick Tip – Easily identify source DHCP server using ESXi DCUI

by Leave a Comment

While installing the ESXi 7.0 Update 1 on one of my physical system, I happened to be in the "Configure Management Network" section of the ESXi Direct Console UI (DCUI) and noticed something I had never seen before. As shown in the screenshot, it now shows the IP Address of the DHCP server in which ESXi received the DHCP lease.


I had not noticed this before and after asking on Twitter, it looks like this is definitely a new enhancement that was added fairly recently. I did not see this in one of my ESXi 6.7 Update 3 deployments, but it may have came in a later patch but definitely new in ESXi 7.0 or greater. Not only is this a quick and easy way to identify the DHCP server being used but in case you need to track down an unexpected rogue DHCP server running, this will certainly come in handy as pointed out by John.

Tanzu Kubernetes Grid (TKG) Demo Appliance 1.2.0

by Leave a Comment

Happy to share that the Tanzu Kubernetes Grid (TKG) Demo Appliance Fling has been updated to support the latest TKG 1.2.0 release which just came out a couple of weeks ago. The TKG Workshop Guide has been updated to reflect all new TKG 1.2 changes along with an updated vSphere Content Library containing all the OVA required to get started. As mentioned in the workshop guide, you can use either a VMware Cloud on AWS SDDC (1-Node) or a vSphere 6.7 Update 3/vSphere 7.0+ environment.

The most notable change with this version is actually within TKG itself which now uses kube-vip to replace the functionality that the HAProxy VM used to provide. What this means when deploying either a TKG Management or Workload Cluster is that you will need to specify an IP Address which will be used for the Virtual IP endpoint of the K8s Cluster as shown in the screenshot below.

tkg init -i vsphere -p dev --name tkg-mgmt --vsphere-controlplane-endpoint-ip 192.168.2.10


Using the TKG Demo Appliance, you can deploy both v1.19.1 and v1.18.8 K8s Clusters. To exercise a TKG Cluster upgrade workflow, you just have to run these three simple commands:

export VSPHERE_TEMPLATE=photon-3-kube-v1.18.8_vmware.1
tkg create cluster tkg-cluster-01 --plan=dev --kubernetes-version=v1.18.8+vmware.1 --vsphere-controlplane-endpoint-ip 192.168.2.11
tkg upgrade cluster tkg-cluster-01


There has been a lot of demand for TKG on VMware Cloud on AWS, so that is where I have spent the bulk of my testing not to mention where it was originally developed. You can also deploy the TKG Demo Appliance in an on-premises vSphere environment running 6.7 Update 3 or newer.

[Read more...] about Tanzu Kubernetes Grid (TKG) Demo Appliance 1.2.0

OVFTool 4.4.1 – Upload OVF/OVA from URL using upcoming “pull” mechanism

by 2 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

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

ovftool \
--X:logFile="ovftool.log" \
--acceptAllEulas \
--allowAllExtraConfig \
--allowExtraConfig \
--noSSLVerify \
--sourceSSLThumbprint="BA:C6:4E:D9:AD:D4:53:B5:86:5A:5D:70:36:CF:89:93:D1:6C:F9:63" \
--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.

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

by 55 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 (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...] about Update on ESXi on Apple Mac Mini 2018 & Mac Pro 2019

Apple Mac Mini on VMware HCL!

by 9 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...] about Apple Mac Mini on VMware HCL!

Quick Tip – Crucial NVMe SSD not recognized by ESXi 6.7 & 7.0

by 65 Comments

If you own or have recently purchased Crucial NVMe SSD such as CT1000P1SSD8 (1TB M.2 NVMe SSD) or CT500P1SSD8 (500GB M.2 NVMe SSD), please be aware that these devices may no be recognized by ESXi after upgrading to the latest release. Thanks to Pete Lindley, (OCTO for End-User Computing), who reached out last week regarding the observation as well as a workaround for the problem. This was also quite timely as I recently purchased a Crucial M.2 NVMe SSD and would have also ran into this problem.

It turns out these Crucial devices were working fine while running on ESXi 6.5 Update 2 but was no longer recognized in latest release of ESXi 6.7 Update 2. It is unclear whether support for these SSDs were removed intentionally or unintentionally, but in either case, these devices are not officially on VMware's Hardware Compatibility List (HCL).

UPDATE (07/29/20) - Over the past few months, I have had a number of folks share feedback that using the trick mentioned below for ESXi 7.0, they have had success of ESXi detecting their NVMe SSD. I wanted to share some of the model and/or vendors that folks have reported success with. I will keep this list updated, so feel free to leave a comment below.

UPDATE (06/13/20) - Thanks to reader Dave, it looks like this trick also works with ESXi 7.0 but the filename has changed. Simply copy nvme.v00 VIB from the ESXi 6.5 Update 2 and replace it on ESXi 7.0 system (either live under /bootbank or part of the installer) but rename the file to nvme_pci.v00 which is the new filename for NVMe driver.

UPDATE (05/23/19) - After speaking with a few folks who took a closer look, the issue is due to the fact that we added support for NVMe 1.3 spec in latest ESXi 6.7 Update 2 release, but because these are "consumer" devices, they did not conform to the latest specification and hence the driver is unable to claim the device. This is another good reminder when using components not on VMware HCL, this is always a risk from a home lab perspective. In general, I know Samsung and Intel NVMe SSD usually works quite well without issues but always good to do some research. I think Engineering is looking to see if there are other workarounds for the future, but for now, you can use the workaround below.

The easy workaround that Pete found was to simply replace the NVMe driver from ESXi 6.7 Update 2 (1.2.2.27-1vmw.670.2.48.13006603) with one found in ESXi 6.5 Update 2 (1.2.1.34-1vmw.650.2.50.8294253). To so do, simply copy nvme.v00 to /bootbank from either an existing ESXi 6.5 Update 2 system or directly from the ISO. Please note, any future updates or patches to the ESXi host will most likely override the updated driver.