Get My Podcast On iTunes!
Badges

vexpert_logo_100x57

gestaltitbadge

follow-me-twitter

Subscribe to me on FriendFeed

Comments / DISQUS
Feedjit.com

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:

“.. I also found some quirks in ESX 3.5 with backward compatibility. I built some Blades BL460c/ESX 3.5 with eva 3000 SAN. Later I put ESX 302 Update1 Build on blades but left VMFS partition (ESX 3.5 Build) intact as it had some VMs on them. These VMs threw some terrible issues with networking in Windows 2003 environment (despite working ok with normal day to day networking ) and it wasn’t until few days after when I discovered that the VMware tools installed from ESX3.5 build were the culprit although no apparantly networking issues were there. Reverting back the Tools versions sorted the problem out.

Morale: ESX 3.5 VMware Tools are not backward compatible on VMs that may [have] to run on [the] ESX 302 platform.”

Related Posts

View Comments to “ESX 3.5 vmtools incompatible with ESX 3.0.x”

  • Scott Lowe says:

    Rich, good catch! For companies running farms with mixed versions of ESX Server, this could be an issue. Thanks for bringing it to light.

  • Jim says:

    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.

Leave a Reply

blog comments powered by Disqus
Support VM /ETC
Support VMETC.com

Support VMETC.com

Free Business and Tech Magazines and eBooks
@rbrambley tweets
VMTN Roundtable Podcasts
Subscribe



Add to Google Reader or Homepage
Subscribe in NewsGator Online
Add to netvibes
Add to Plusmo