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.
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.
[Read more...] about Enhancements to the community ne1000 VIB for Intel NUC 10
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.
[Read more...] about How to patch Intel NUC 10 with latest ESXi 7.0 update?
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.
[Read more...] about Passthrough of Integrated GPU (iGPU) for standard Intel NUC
With the vSphere 7 Launch Event just a few days away, I know many of you are eager to get your hands on this latest release of vSphere and start playing with it in you homelab. A number of folks in the VMware community have already started covering some of the amazing capabilities that will be introduced in vSphere and vSAN 7 and I expect to see that ramp up even more in the coming weeks.
One area that I have not seen much coverage on is around homelab usage with vSphere 7. Given this is a pretty significant release, I think there are some things you should be aware of before you rush out and immediately upgrade your existing homelab environment. As with any vSphere release, you should always carefully review the release notes when they are made available and verify the hardware and its underlying components are officially on the VMware HCL, this is the only way to ensure that you will have a good and working experience.
Having said that, here are just a few of the observations that I have made while running pre-GA builds of vSphere 7 in my own personal homelab. This is not an exhaustive list and I will try to update this article as more information is made available.
Disclaimer: The following considerations below is based on my own personal homelab experience using a pre-GA build of vSphere 7 and it does not reflect any official support or guidance from VMware. Please use these recommendation at your own risk.