As shared back in 2022 in my Homelab Considerations for vSphere 8.x blog post, if you attempt to install ESXi on system where the CPU is no longer being supported by the OEM vendor, who then informs VMware on what to publish on the VMware Hardware Compatibility Guide (VCG), you will see the following error message preventing you from proceeding.
Also mentioned in that article, you can override this default behavior with the following ESXi boot option: allowLegacyCPU=true which would convert this from an error to warning message but allowing you to proceed in an installation or upgrade.
Obviously, this is not officially supported by VMware and its behavior was never guarantee but it certainly was a nice gesture, in my humble opinion from Engineering, as they could have easily not allowed any override based on on our official VCG. For homelab use cases, it might be okay to use a CPU that is 5 to 6 years old, knowing that it should be replaced hopefully in the near future.
I just had a couple of users report issues while upgrading to the latest ESXi 8.0 Update 2 release when using the allowLegacyCPU boot option and saw the following error message
VMB: 716: Unsupported CPU
The ESXi installer immediately halts and prevents the upgrade from proceeding ...
Since this was only the second occurrence of this issue, still waiting to hear back from the first reported issue, I thought I would check with Engineering to see if there was any changes in latest ESXi 8.0 Update 2 release because I was not able to reproduce this with my oldest system, which was a 2011 Apple Mac Mini.
It looks like with ESXi 8.0 Update 2, we now have a minimum requirement for a CPU processor to support the XSAVE instruction, which was introduced back in 2011 with both Intel Sandy Bridge and AMD Bulldozer processors.
The CPU that this user was attempting to install ESXi is an Intel Westmere, which was prior generation to Sandy Bridge and does NOT support the XSAVE CPU instruction and this is why the installer is preventing the installation even when the override boot option is provided. As of publishing this blog post, you can still go up to ESXi 8.0 Update 1c and anything that maybe released in future that incorporate this requirement, you will not be able to install and/or upgrade to.
While I am sympathetic in prolonging hardware for homelab use cases, especially what looks to be functional hardware, but I think a refresh is probably needed if you are trying to use a CPU that is more than a decade old 🙂
Despite I am not running vsphere 8.0 on such old machine it just remembered me similar problem/failure when I was trying to deploy NSX 3.2 edges on Westmere-EP CPUs in my lab which leaded to decision to grab something more recent:)
Hey Will,
Any reports of issues with Ivy Bridge type system not being able to update to 8.0u2
DIdn't work for me with a Xeon E5-2680 v2 which is Ivy Bridge. Mine is also listed here on Table 2 under "Discontinued" 🙁
https://kb.vmware.com/s/article/82794
ESXi 8.0 Update 2 also breaks the ability for the nvme_community fling to load properly for the onboard PCIe NVMe SSD inside a 2018 Mac mini so the datastore is gone!
Interestingly it still does load for external TB3 connected NVMe devices!
The community nvme fling worked just fine in the prior build of 8.0U1c
William, do you know if there is a fix so we can upgrade from 8.0U1c to 8.0U2 on the 2018 Mac Mini?
The NVMe Community Fling has been deprecated for some time and not to mention our support stance for Apple Mac Mini (that was part of the factor of deprecation and Engr folks no longer had cycles to support Fling). Also, there's no assumption of forward compatibility even with supported drivers, so I wouldn't say "break" is the right word. We never planned to support it beyond what was doc'ed in Fling, if it happens to function for newer releases, it was purely accidental.
Thanks William, understood.
However after it worked so well with 8.01c I had really hoped it would also work for 8.0U2...
I wonder if this is related to a purple screen error I am seeing on a Xeon E5-2699v4 on a Dell Precision 5810. Newer machine, and it is listed as a compatible CPU in VMWare's compatibility matrix. I am getting a purple screen when updated to 8u2 or fresh install attempt to 8u2 with the error "TSCs are out of sync". First time I've ever seen that error. I updated a host that was running an E5-2690(v1) CPU to 8u2 so I know that it will run on that generation CPU. Very weird error.
TSC is not related, I think I saw someone report similar issue. Let me see if there any resolution/workaround. Are you able to provide any logs or console output?
I definitely have a picture of the console showing the crashdump. I can email it your way.
Broadwell is no longer supported as of vSphere 8.0 (See https://williamlam.com/2022/09/homelab-considerations-for-vsphere-8.html which lists processors that were removed)
If you're able to rollback, it looks like you can try:
esxcli system settings kernel set -s tscSyncSkip -v TRUE
AND then attempt the upgrade and see if you're still getting PSOD. If you've already upgraded, then the setting won't help
Broadwell-EP is still supported as of vSphere 8.0 U2, which includes the Xeon E5-2699v4 server CPU generation.
https://www.vmware.com/resources/compatibility/detail.php?scat=cpu&productid=111
Broadwell-DT/H are not supported, but those a desktop processors.
Unfortunately this is exactly why I try to upgrade every 3-4 years. Anyone looking for a cheap enterprise grade esxi host, go look at used dell precision 7820's. Poor mans r640, runs esxi superbly, Skylake or cascade lake CPUs which are cheap now and up to 768gb of RAM. And they can do multiple gpus.
Which is also inline with most organizations hardware refresh cycles (3-5 years). Being able to get decade+ out of the hardware is pretty darn fantastic and anything more is simply luck 🙂
is there solution to code 43 in intel hd 4600 gpu passthrough ?
No, Intel issue. Also this isn’t related to topic …
I am using Intel x5690 CPU.
It was working on 8.01.
After I upgraded to 8.02, it has same error.
AllowLegacyCPU=true did not work
Did you even bother to read the blog post .... x5690 shows up as Westmere