virtuallyGhetto

William Lam

MacOS 11 (Big Sur) Beta 1 on ESXi

by 10 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 – Certificates in Apple Keychain causes Terraform init to fail with Registry service unreachable

by 1 Comment

I have been struggling with an interesting Terraform issue on my MacOS system where running the "init" operation would throw the following error:

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...

Registry service unreachable.

This may indicate a network issue, or an issue with the requested Terraform Registry.

Error: registry service is unreachable, check https://status.hashicorp.com/ for status updates

This was extremely frustrating to debug which I had filed a Github issue here. From what I have gathered, this actually had nothing to do with connectivity to the HashiCorp endpoint which works perfectly but probably was related to some other issue. What was even more strange was that using "sudo" which another user reported in an older issue allowed the operation to go through. I was also not having this problem on my other MacOS system, so I knew this was probably environmental but was running out of ideas to try.

I took another look this past weekend while doing some testing and I stumbled onto this thread here which the user found the real root cause. It looks like certain certificates within Apple Keychain Access, possibly related to Microsoft Remote Desktop that have expired was actually causing the problem. When I took at look at the Keychain Access login->certificates, I saw a number of certificates which had expired but were still marked trusted. After removing these entries (although this can be automated using the security utility, it was not trivial given the lack of arguments to quickly list out expired certificates), that I simply used the UI to delete the entries.

Once all the expired certificates were removed, I was able to successfully perform the Terraform init operation! I have already shared this update in my Github issue and hopefully this error message can be improved in the future as it was very miss-leading on the actual issue.

Passthrough of Integrated GPU (iGPU) for standard Intel NUC

by 1 Comment

Earlier this week I found out that it was possible to passthrough the Integrated GPU (iGPU) for standard Intel NUC which was motivated by a question I had saw on the VMware Subreddit. I have written about iGPU passthrough for Intel NUCs before but only for the higher end models which were the Hades Canyon NUC at the time.

To be honest, I never thought about trying this out with a standard NUC as I figured the iGPU may not be powerful enough or warrant any interests. After sharing the news on Twitter, I came to learn from the community that not only is this desirable for various use cases but some folks have also been doing this for some time now and have shared some the benefits it brings for certain types of workloads.

Below are the instructions I used to enable iGPU passthrough on an Intel NUC 10 (Frost Canyon) with vSphere 7.0. These instructions should also be applicable for other NUC models and earlier versions of vSphere including details around passthrough configuration persistency which I know some folks have ran into which I was able to figure out as part of this experiment.

[Read more...] about Passthrough of Integrated GPU (iGPU) for standard Intel NUC

Quick Tip – HTTPs now supported with wget on ESXi 7.0

by 1 Comment

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! 😍

[[email protected]:~] 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.

[[email protected]:~] 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.

Updating the VSAN HCL & Release Catalog DB using VSAN API

by 2 Comments

Both the VSAN Hardware Compatibility List (HCL) and the VSAN Release Catalog database which provides VSAN build recommendations should be updated periodically to ensure that you have the latest VSAN recommendations from VMware. In addition to using the vSphere UI to perform these update, customers can also automate either of these tasks using the VSAN Management API which can be consumed using any of the supported VSAN Management SDKs including PowerCLI.


I recently had a question about which VSAN API to use to update VSAN Release Catalog.

[Read more...] about Updating the VSAN HCL & Release Catalog DB using VSAN API

Full OVA/OVF property support coming to Terraform provider for vSphere

by 5 Comments

Terraform is one of the most popular Infrastructure as Code (IaC) tool out there today and it should come as no surprise there is Terraform provider for vSphere which many of our customers have been using. In fact, VMware just recently released a couple more new providers (here and here) supporting VMware Cloud on AWS and NSX-T solutions respectively.

Although I have used Terraform and the vSphere provider in the past, it has not been my tool of choice for automation as it still lacks a number of basic vSphere capabilities which I require on a regular basis. The most common one being the ability to deploy a Virtual Appliance (OVA/OVF) which has been my biggest barrier and I know this has been a highly requested feature from the community as well.

In early May of this year, I noticed that v1.18 of the vSphere provider finally added support for OVA/OVF deployment and I was pretty excited to give this a try and may even have been the first to kick the tires on this feature? Although OVA/OVF support was added, it looks like support for customizing OVF properties which is commonly included as part of an OVA/OVF would only possible if you are cloning from an existing imported OVA/OVF image. One of the most common use case is to import an OVF/OVA from either your local computer or from a URL and it looks like this use case was not possible.

I filed two Github issues, one for supporting OVF properties for initial OVA/OVF deployment and another regarding a bug I ran into when importing OVA/OVF from a remote URL. Just yesterday, I got the good news that my feature request has been completed and I was given an early drop of the vSphere provider to try out this feature. I may have also hinted to the Engineering team to use my popular Nested ESXi Appliance OVA as a reference test implementation as I knew this was something many customers will want to deploy 🙂

UPDATE (06/23/20) - Support for OVA/OVF properties is now available as part of 1.20 of the Terraform Provider for vSphere

[Read more...] about Full OVA/OVF property support coming to Terraform provider for vSphere