WilliamLam.com

Search Results for: Intel NUC

Passthrough of Integrated GPU (iGPU) for Apple Mac Mini 2018

by // 39 Comments

After successfully enabling and persisting the passthrough of the iGPU for the latest Intel NUC 10 (Frost Canyon), I thought it was worth experimenting with the Apple Mac Mini 2018 to see if the same could be accomplished with its iGPU, which is an Intel UHD 630. The biggest benefit in addition to unlocking the iGPU for general use is support for Apple's Metal API which gives developers access to the underlying GPU when building and testing MacOS and iOS applications. This is also quite timely as the Apple Mac Mini 2018 was just added to the VMware HCL!

My initial attempt failed when using the latest ESXi 6.7 Update 3 release. After enabling passthrough of the iGPU and rebooting the ESXi host for the change to take affect, the system would get stuck during boot up when loading the dma_iommu_mapper module. After speaking with Engineering, the issue is probably not related to dma_iommu_mapper module but some other module shortly after but without serial console output or ability to see terminal screen, it would be very difficult to debug the issue.

About to give up, my last attempt was try ESXi 7.0 and to my surprise the ESXi host fully booted up after enabling passthrough of the iGPU. It is still not clear on what might be causing the problem for 6.7 but at least 7.0 works!

Note: To be able to successfully power on a MacOS VM running on ESXi 7.0, ensure you have applied the recent ESXi 7.0b patch. You will need to go to the VMware Patch Portal siteto download and apply the update.

Step 1- Enable passthrough of the iGPU using the vSphere UI and then reboot for changes to take affect.

Step 2 - Navigate to Configure->Hardware->Graphics->Host Graphics and change the default graphics type to "Shared Direct"

[Read more...]

Heads Up - Nested ESXi crashes in ESXi 7.0 running on older CPUs

by // 27 Comments

Thanks to Patrik Kernstock, who works in our Technical Support organization at VMware, for making me aware of an issue related to Nested ESXi running on an ESXi host that has been upgraded to ESXi 7.0. Several folks in the community have noticed after upgrading their Intel NUC 7th Gen and deploying a Nested ESXi VM and powering on an inner-guestOS would causes the Nested ESXi VM to crash.

Upon further investigation, it looks like this is not specific to the Intel NUC platform but rather with a specific generation of CPUs which are Intel Sky Lake-based and as a result, some customers are noticing this affect on their 7th Gen NUC.

UPDATE (06/23/20) - ESXi 7.0b has just been released and contains the fix for the Nested ESXi VM crash. If you are using an Intel NUC 10, do not just apply the patch as the updated ne1000 VIB within the patch will override existing Intel NIC driver causing the network adapter to no longer function. It is recommended that you download the patch and replace the default ne1000 VIB using Image Builder with the Intel NIC version before applying the update. To download the patch, please visit VMware Patch Portal site.

The good news is that this issue has already been reported and we should have a fix in a future update of ESXi. In the meantime, you can still run Nested ESXi and Nested Virtualization on these affected CPUs, you just will not be able to power on inner-guest VMs. Big thanks to Patrik for helping out with the testing and triaging this internally.

Quick Tip - Allow unsupported CPUs when upgrading to ESXi 7.0

by // 69 Comments

As outlined in the vSphere 7.0 release notes (which everyone should carefully read through before upgrading), the following CPU processors are no longer supported:

  • Intel Family 6, Model = 2C (Westmere-EP)
  • Intel Family 6, Model = 2F (Westmere-EX)

To help put things into perspective, these processors were released about 10 years ago! So this should not come as a surprise that VMware has decided remove support for these processors which probably also implies the underlying hardware platforms are probably quite dated as well. In any case, this certainly has affected some folks and from what I have seen, it has mostly been personal homelab or smaller vSphere environments.

One of my readers had reached out to me the other day to share an interesting tidbit which might help some folks prolong their aging hardware for another vSphere release. I have not personally tested this trick and I do not recommend it as you can have other issues longer term or hit a similiar or worse situation upon the next patch or upgrade.

Disclaimer: This is not officially supported by VMware and you run the risk of having more issues in the future.

Per the reader, it looks like you can append the following ESXi boot option which will allow you to bypass the unsupported CPU during the installation/upgrade. To do so, just use SHIFT+O (see VMware documentation for more details) and append the following:

allowLegacyCPU=true

There have also been other interesting and crazy workarounds that attempt to workaround this problem. Although some of these tricks may work, folks should really think long term on what other issues can face by deferring hardware upgrade. I have always looked at homelab as not only a way to learn but to grow yourself as an individual.

Note: The boot option above is only temporarily and you will need to pass in this option upon each restart. It looks like this setting is also not configurable via ESXCLI which I initially had thought, so if you are installing this on a USB device, the best option is to edit the boot.cfg and simply append the parameter to kernelopt line so it'll automatically be included for you without having to manually typing this. If this is install on disk, then you will need to edit both /bootbank/boot.cfg and /altbootbank/boot.cfg for the settings to passed in automatically.

This is ultimately an investment you are making into yourself, so do not cut yourself short and consider looking at a newer platform, especially something like an Intel NUC which is fairly affordable both in cost as well as power, cooling and form factor.