vsphere_static_160x300
Badges

vexpert_logo_100x57

gestaltitbadge

follow-me-twitter

Subscribe to me on FriendFeed

Comments / DISQUS
Tag Cloud
Feedjit.com
«
»

ESX 3.5 vmtools incompatible with ESX 3.0.x

PostDateIcon January 23rd, 2008 | PostAuthorIcon Author: Rich Brambley

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

PostCategoryIcon Posted in esx, vmtools | PostTagIcon Tags: , , , , , , ,
«
»
  • Jim
    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.
  • Rich, good catch! For companies running farms with mixed versions of ESX Server, this could be an issue. Thanks for bringing it to light.
blog comments powered by Disqus
Hyper9 Cowabunga
Support VM /ETC
Support VMETC.com

Support VMETC.com

Free Business and Tech Magazines and eBooks
@rbrambley tweets
Advertisements
Facebook
VMETC
VMETC
Promote Your Page Too
VMTN Roundtable Podcasts
Subscribe



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

License
Creative Commons License
www.vmetc.com by Richard Brambley is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

Contact Us | Terms of Use | Trademarks | Privacy Statement
Copyright © 2009 VM /ETC. All Rights Reserved.

Powered by WordPress and WordPress Theme created with Artisteer.