This is an old post but one that keeps coming up in search results and as such I think this deserves an actual answer rather than regurgitation of the existing Knowledge Base articles.
***Disclaimer***
I am not a VMware employee and this post does not imply that what I am proposing is supportable by anyone, including myself.
The information below is "accurate" up through and including vSphere 6.5, in that upgrading the VM Hardware Version in and of itself does NOT modify anything but the config.version line of the .vmx file.
Updated Virtual Machine Hardware Versions give you access to either additional functionality, higher resource limits or new/different hardware. Within the .vmx file is one line that is read by the ESX host or vCenter when registering the VM:
virtualHW.version = "8"
That line tells VMware/ESXi what capabilities should be presented and/or allowed when configuring this virtual machine, and or prevents the VM from being added to the inventory if the underlying host cannot provide functionality that the VM could request. It is also worth noting that during registration (import), vSphere/vCenter will parse the .vmx file to ensure that it understands everything in it and that it doesn't contain illegal configuration lines, etc. Changing the hardware version itself does nothing other than edit this line. This line is CRITICALLY important when troubleshooting why a VM won't power on or even register, however.
If you upgrade the hardware version but do nothing else, a downgrade truly is as simple as editing the .vmx file. It needs to be powered off (because it's locked) but doesn't even need to be removed from inventory if you have shell access to the console or SSH access to issue a couple of commands. Beyond the scope of this answer though.
The magic happens when you leverage those new, expanded capabilities. That puts entries into your .vmx file that are no longer compatible with the older, lower hardware versions.
Example:
- Upgrade hardware version from 10 to 11
- Increase memory from 1011 GB to 1012 GB
- vMotion to a 5.5 ESX host
The VM will not power on (and potentially won't even vMotion) because you have done something to the VM that the underlying ESX host cannot support. In this case, the fix is simple:
- Edit the .vmx file, and;
- Change the amount of memory to 1011 GB (do the math yourself...I mean, c'mon)
- Change the virtualHW.version = line to 10
- Re-register the VM
- Power on
More complex changes become more difficult (if not impossible) to roll back, hence the creation of the KB and the suggestions therein.
Now, for the reason this isn't in a KB. You can SCREW THIS UP very, very easily. All you have to do is change something you didn't realize you had changed or, worse, future hardware versions DO make other changes, and you are hosed. For example, if another admin adds a type of disk that isn't supported by down-level versions, you will get an error when you try to register the VM. In their defense, VMware has less than no desire to have to troubleshoot every admin manually poking around in the .vmx file, even for a "simple" roll-back of a hardware version upgrade, and they shouldn't have to. Very few things need to be edited manually, too many things can go wrong (making a backup before you start tinkering should go without saying).
So, the TLDR version is:
If you don't modify your VM to leverage any new functionality provided by the upgraded hardware version, rolling back can be accomplished by editing the .vmx file and refreshing the registration or re-registering the VM (remove and re-add).
If you have used any new functionality, you have to undo those changes before rolling back or use one of the supported solutions from the KB. Understand that not all changes "undo" cleanly so the suggestions in the KB do in fact have merit.
It is important to note that "unsupported" doesn't mean "won't work", it just means that if it blows up in your face, you own it.
Dave