With the upcoming release of vSphere 7.0 Update 1 and specifically ESXi 7.0 Update 1, support for the onboard NIC of the Intel NUC 10 (Frost Canyon) is now included and the community ne1000 VIB driver is no longer needed. If you had previously installed the community driver, you can uninstall the VIB after successfully upgrading to ESXi 7.0 Update 1.
Search Results for: intel NUC
For Intel NUC 10 (Frost Canyon) owners who have installed ESXi may have noticed that even after disabling Intel's Trusted Platform Module (TPM), the following warning message "TPM 2.0 device detected but a connection cannot be established." is still being displayed in the vSphere UI as shown in the screenshot below.
Thanks to Reddit member mscaff and casperette who recently discovered and confirmed that the latest BIOS (FN0044) resolves an issue where disabling TPM in the BIOS was not actually working which would explain the behavior observed above. The really interesting thing is that I had initially ran into this problem several months back and after speaking with some internal VMware folks, I was able to get rid of this message without this update. This involved installing Windows 10 and clear the TPM keys which may have still been cache but since then, it has not been reproducible by other folks. In any case, it is always recommended to check and update to latest BIOS to ensure you have all the latest bug fixes.
Lastly, Intel states support for TPM 2.0 for these NUCs, so why is ESXi complaining? Well, it has to do with the interface type and not with SHA1 vs SHA256 which are both supported on the NUC 10. The NUC only supports CRB but proper compliant TPM 2.0 chip must support FIFO which is not configurable the last time I had checked. For more detail requirements and configuration of TPM 2.0 on ESXi, please refer to this blog post.
As many of you know, the onboard Intel NIC (8086:0d4f) found in the 10th generation of the Intel NUC (Frost Canyon) is not automatically recognized by ESXi and requires an updated ne1000 VIB which was released earlier this year. An unfortunate side affect after patching or upgrading an ESXi host which contains this modified ne1000 VIB is that it will be replaced by a newer version of the VIB and causes the NIC to no longer be recognized again.
A quick workaround is to simply re-install the modified ne1000 VIB and network connectivity will be restored which is less than ideal. A new vSphere Image Profile can also be created that contains both the patch/upgrade you intend to apply along with the modified ne1000 VIB, ensuring that you remove the newer version which may not be ideal as well. In speaking with Songtao, a VMware Engineer who I worked with on the USB Network Native Driver for ESXi, about this issue and he came up with a very simple solution. Lets choose a different name for the VIB module which removes all the complexity mentioned above. This solution would allow for both drivers to coexists and more importantly, it is persistent across patching and upgrades of ESXi.
vSphere 7.0b was just released last week and one of the important fixes was to resolve an issue where Nested ESXi VMs were crashing upon powering on an inner-guest VM. This looks to have also affect newer generations of CPUs including Intel's 10th Gen Comet Lake which is also found in the latest 10th Gen Intel NUCs (Frost Canyon).
A number of folks quickly found that if you simply applied the ESXi 7.0b patch, an unexpected behavior occurred on the 10th Gen Intel NUCs and the onboard networking was lost upon a reboot. This occurs as the original ne1000 driver which had been replaced with a newer version found within ESXi 7.0b no longer recognizes the onboard Intel NIC. The solution is quite simple, create a new Image Profile that contains the Intel NUC NIC Driver.
Several of you have asked for instructions and although this is a pretty common vSphere workflow, I have documented the two supported options using the vSphere Image Builder utility but there are definitely other methods which will have the same results. If you have access to a vCenter Server 6.7 or newer, I recommend using the Image Builder UI. If vCenter Server access is not available, then you can use Image Builder with PowerCLI, however you will need to have access to a Windows machine as the Image Builder cmdlet is not supported with PowerCLI Core.
Note: There is currently a known bug with the Image Builder UI when using vSphere 7 which will prevent you from authoring a new Image Profile. A workaround would be to deploy a VCSA 6.7 which does not have this issue when looking to use the Image Builder UI.
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) 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.
Swift Canyon, Baby Canyon, Bean Canyon, Provo Canyon, Kaby Lake, Whiskey Lake, Coffee Lake ... these are just some of the Intel codenames that either refer to a NUC platform or CPU generation. I can understand the need for codenames, however for consumers, the various names are often confusing and being able to grok at which system is the "latest" is not always trivial. In some cases there are multiple updates to different generations of the platform all happening within a short period of time and most online sites may swap between codenames and the official "Nth" generation nomenclature.
I have been working with the Intel NUC platform from a VMware standpoint since the 6th Generation back in 2016 and even I still get confused at times on what is the latest "Canyon" NUCs and their respective "Lake" CPU generations. I can not imagine how complicated this might feel for some of our customers who are updating their VMware homelab every couple of years or someone who is just starting out for the first time. To not only help keep myself sane as I often get asked about Homelabs, literally on a weekly basis and to help educate others within out community, I have created a document which maps all Intel NUCs (full height) to their respective Nth generation along with the respective CPU architecture used in each platform.