WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

MacOS 11 (Big Sur) Beta 1 on ESXi

06.24.2020 by William Lam // 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)

Categories // Apple, ESXi, vSphere 7.0 Tags // Big Sur, ESXi 6.7, ESXi 7.0, macOS

Quick Tip - Certificates in Apple Keychain causes Terraform init to fail with Registry service unreachable

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

Categories // Uncategorized Tags // keychain, Terraform

Passthrough of Integrated GPU (iGPU) for standard Intel NUC

06.18.2020 by William Lam // 35 Comments

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.

Neat! Just found out you can actually passthrough the iGPU of standard Intel NUC. The trick looks to be enabling passthrough using ESXi Embedded Host Client UI & then you can assign it using vSphere UI#Homelab pic.twitter.com/NwuxbXwUMj

— William Lam (@lamw.bsky.social | @*protected email*) (@lamw) June 15, 2020

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.

Can’t take credit. It was one of our collegaues that pointet me to it. Hw transcoding went up a factor of almost x 20. So for specefic workloads the nuc is suddently a lot more capable than before.

— Robert Jensen (@rhjensen) June 15, 2020

I’ve been doing this forever, when I need to crack passwords but don’t need the full 7 gpu rig - all Supermicro and 1080ti GPUs these dayshttps://t.co/GJGRV5eu8f

— Rob VandenBrink (@rvandenbrink) June 15, 2020

seems like this would be great for ESXi + Plex hardware transcoding

— Will Beers (@willbeers) June 15, 2020

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...]

Categories // ESXi Tags // ESXi 7.0, GPU, Intel NUC, Passthrough

  • « Previous Page
  • 1
  • …
  • 235
  • 236
  • 237
  • 238
  • 239
  • …
  • 614
  • 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
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Quick Tip: How to Identify Which Kubernetes Cluster Owns a vSphere Container Volume (PV) 06/25/2026
  • What Host Lifecycle Operations Are Available after Importing vCenter into VCF 9.x Fleet? 06/24/2026
  • VCF 9.1 - Enabling High Availability for a Small VCF Management Services (VCFMS) Deployment 06/22/2026
  • Clarifying Minimum Required ESX Hosts for VCF Deployments 06/18/2026
  • VCF 9.1 - Auditing VCF Management Services (VCFMS) IP Pool Usage  06/17/2026
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 © 2026

Loading Comments...