ESXi 6.7 Unsupported CPU – Ideas for workarounds

This post was originally published on this site

Hi All,


With the recent release of vSphere 6.7 many of us who built home lab environments just hit a dead end on the upgrades due to CPU incompatibilities. Taking the fact that some of us have built quite extensive versions of the labs with rather expensive equipment, it makes a situation even more difficult, since if we would like to upgrade all the back-end equipment then this would require tremendous financial support which we usually can’t get out of nowhere. So I was thinking about some potential workarounds with hopes that some of you may pop into this discussion and provide additional ideas.


In my lab I have various types of machines some of which are fully supported at this time for running ESXi 6.7 but the question of “until when ?” is always out there. So far I managed to run most of my hardware up till ESXi 6.5 without any issues regardless of the warning message that my CPU’s are falling into the scope of unsupported stuff, but oh well we never care about such warnings when it comes to home labs right ?


Anyway so my stuff is organized as follow. I have one ESXi Cluster based on Xeon E5-2620 CPU’s which runs absolutely fine with ESXi 6.7, however I have another ESXi Cluster based on older Intel Core i7-950 CPU’s and I’m using it for testing some vCloud Director related VCD features. Unfortunately this second cluster definitely doesn’t fall into the scope of upgrading it to ESXi 6.7 and for my worst luck it just refused to boot up when I tried to enforce it to v6.7 via the offline-depot upgrading method. The machines were always getting back to the black screen stating that my CPU type is unsupported.


Personally I’m not very happy with VMware’s decision on completely dropping out the older CPU’s because this seriously limits the options for home labs and frankly I don’t even think we usually test the most complex features requiring the additional hardware support. Of course I agree to some extend with the decision to limit support for extremely old machines and especially when it comes to production environment, but on the contrary I have another very old ESXi cluster based on Intel Core 2 Quad Q9550 CPU’s which still totally works with ESXi 6.5 and I’m using it occasionally for testing out vCloud Edge related services. So I found it kinda unnecessary that VMware went too drastic on this decision instead of letting the home-lab users to test out on their own equipment what may or may not work. Anyway…


So in my case upgrading the hardware from scratch on at least two cluster of 3 machines to new generation is totally going to drain my finances and therefore I started to look for some workarounds to this. My main idea here was to try the nested-virtualization method by installing ESXi 6.7 on the top of ESXi 6.5 layer and enforce the VM via CPUID modifications to actually think that it does have a supported CPU class underneath. I took the approach by making a test VM on one of my Intel Core i7-950 CPU based machines (still running ESXi 6.5). When I boot the VM and try to install ESXi 6.7 the obvious result was this one:



At this point I decided to play around a bit with the EAX registers and implement a mask that would enforce ESXi 6.7 to think the VM has a different CPU model and stepping. Since my knowledge on CPUID implementation is somewhat limited I just decided to take the EAX register from one of my Intel E5-2620 based hosts instead:



Once I applied the mask, I was able to install ESXi 6.7 without any issues. I didn’t even have to rebrand the CPU via the 0x80000002 registers in order to be able to install the new OS, so it seems that ESXi 6.7 is primarily looking at the CPU Family ID, model and stepping for the initial CPU identification procedure.



While this method is not ideal at all (in fact it’s a very ugly workaround) at least it provided the option to install the new OS and therefore to put hands on the basic functionality. Not sure if this method is suitable for nested virtualization, but if I get some time I’ll definitely test it out. I suppose the EAX registers could be tweaked a bit better in order to be able to support certain set of features, so if anyone has a good idea on how to craft a better CPUID EAX registers purely for lab uses with as much compatibility on features as possible, feel free to put your magic in this thread.


Any other workarounds on running ESXi 6.7 on unsupported CPU’s are also very much welcomed.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.