WilliamLam.com

MacOS 11 (Big Sur) Beta 1 on ESXi

by // 15 Comments

The first Beta of Apple MacOS 11 (Big Sur) was just released a couple of days ago and I know folks are excited to start kicking the tires. Some folks have noticed when to installing Big Sur running on VMware Fusion, the following error is observed:

BIErrorDomain error 3


From the suggested workarounds, it looks like the MacOS installer was somehow unable to detect that the underlying hardware was Apple which causes this generic error to be thrown. Interestingly, this was the same error I came across when attempting to install Big Sur on ESXi 7.0. Instead of having to lookup your physical Apple hardware IDs and specify several VM Advanced Settings, you can simply add the following setting which will accomplish the same behavior:

smbios.reflectHost = "TRUE"

After the setting has been applied, the error should go away and you should be able to upgrade from an existing MacOS deployment to Big Sur. This issue has already been reported internally at VMware and I have also shared with the teams the quick workaround.

Here is Big Sur on ESXi 7.0 running on an Apple Mac Mini 2018 (requires ESXi 7.0b patch VMware-ESXi-7.0b-16324942)


Here is Big Sur on ESXi 6.7 Update 3 running on an Apple Mac Mini 2018 (requires ESXi 6.7 Patch 02 ESXi670-202004002)

Quick Tip - HTTPs now supported with wget on ESXi 7.0

by // 4 Comments

This morning I needed to install the USB Network Native Driver Fling for ESXi and realized that offline bundles can not be installer over a remote URL. I figure I would download it directly to my ESXi host using wget. As soon as I hit the enter key to send the command I quickly remember that this will fail as the version of wget in the ESXi Shell does not support HTTPs. To my surprise, it actually worked! 😍

[root@nuc:~] wget https://download3.vmware.com/software/vmw-tools/USBNND/ESXi700-VMKUSB-NIC-FLING-34491022-component-15873236.zip
Connecting to download3.vmware.com (184.29.106.37:443)
ESXi700-VMKUSB-NIC-F 100% |**************************************************************************************************************************************************************************| 341k 0:00:00 ETA

This looks to be an enhancement in ESXI 7.0 and you no longer will get the "bad address" error when specifying an HTTPs URL as shown in the example below when running against the latest ESXi 6.7 Update 3 release.

[root@esxi67:~] wget https://download3.vmware.com/software/vmw-tools/USBNND/ESXi700-VMKUSB-NIC-FLING-34491022-component-15873236.zip
wget: bad address 'download3.vmware.com'

Thank you to the Engineer who fixed this, this was a very pleasant and welcome surprise that I know will also be helpful to folks who automate using ESXi Scripted Installations.

Admin account for embedded Harbor registry in vSphere with Kubernetes

by // 3 Comments

After setting up a vSphere with Kubernetes Cluster, customers have the option of enabling a built-in private container registry that can be used with the Supervisor Cluster. This private container registry uses the popular Opensource Harbor solution which is also a Cloud Native Computing Foundation (CNCF) project.


Although this is a convenient capability, one thing to be aware of is that the embedded Harbor registry is limited in functionality compared to a standalone Harbor deployment and this is by design. When logging into Harbor with your vCenter SSO user, you will be able to do perform basic operations such as pushing and pulling images from this registry. For customers that require additional functionality from Harbor, it is recommended that you setup an external Harbor instance which can also be used as a common registry for both the Supervisor Cluster as well any Tanzu Kubernetes Grid (TKG) Clusters that you may provision.

With that said, I have heard from a few folks who were interested in accessing the Harbor UI using the "admin" account, mostly from an exploration standpoint. The admin credentials for Harbor are dynamically generated each time the service is enabled and it is stored as a K8s secret within the Supervisor Cluster. This means the admin password is unique for each environment and the instructions below will show you how to obtain the credentials.

UPDATE (12/16/20) - I was informed by Engineering the ability to read K8s secrets was actually a bug and this has since been fixed in the latest release of vSphere with Tanzu. If you need the harbor credentials, you will need to directly login to the Supervisor Cluster from the VCSA (instructions have been updated below) to retrieve this information.

Disclaimer: This is not officially supported by VMware and the behaviors described below could change in the future without notice.

[Read more...]