ESX 3.5 vmtools incompatible with ESX 3.0.x
One of the cool things about this blog is I am communicating with and learning from virtualization professionals all over the world. Recently I received an email from a reader in the UK, Mohammad, who notified me of a couple ESX 3.5 upgrade issues he has experienced. One of his issues, and the topic of this post, is a painful example of the need to understand the compatibility matrixes published by VMware before upgrading to VI3.5.
From Mohammad’s email:












Rich, good catch! For companies running farms with mixed versions of ESX Server, this could be an issue. Thanks for bringing it to light.
This actually makes a lot of sense when you think about it.
When ESX changes major versions (2.x to 3.x) then what the aliens in engineering are doing is virtualizing a new motherboard config. That’s how they go from 2 CPUs to 4 CPUs. They are literally changing the virtual hardware your VMs run on. When you go from 3.0.x to 3.5.x then you’re not changing underlying motherboard, but you are going to get different tools or tweaks out of the VMtools. This could be as significant as changing the virtual machine bios level or it could be simple optimization code for functionality that’s already there.
When you go to 3.5 sure there’s going to be a tools update. 3.0.anything isn’t going to know how to read that new code. It simply doesn’t understand the instruction set. What should continue to work is taking a VM from 3.0.x and running it *without* upgrading tools on a 3.5 platform. VC is going to complain about tools being out of date, and you might see some degraded performance compared to 3.5 native machines, but it should continue to work. If you don’t upgrade your tools versions for a while, you ensure you have a rollback capability should things go horribly wrong in the first 2 or 3 weeks.