Once I applied the mask, I was able to install ESXi 6.7 without any issues. 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: When I boot the VM and try to install ESXi 6.7 the obvious result was this one:Īt 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.
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). 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. 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. 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. 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.
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. The machines were always getting back to the black screen stating that my CPU type is unsupported. 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.
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. 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 ?Īnyway so my stuff is organized as follow. 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 I was thinking about some potential workarounds with hopes that some of you may pop into this discussion and provide additional ideas.
TESTOUT LAB WORKAROUND UPGRADE
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. 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.