ESX 3.5u2v2 Version Difference (3.5.110181 v released binaries at 3.5.110268) from Upgrade to Fresh Install - Reasons?

[i4004]

Like everyone else we've already installed the August 12 time license bomb patch that VMware released (listed as ESX350-200806812-BG). Anyway all our ESX 3.5u2 version 2 servers are now listing themselves as having ESX v3.5.110181. However we have since upgraded all our CD/DVD binaries at they're listed as version v3.5.110268.

I thought that perhaps some versioning misrepresentation was going on so i did a vmware -v at the CLI ans sure enough i get a return of VMware ESX Server 3.5.0 build-110181 from the console of all our ESX servers that were upgraded using the original ESX 3.5u2 CDs and then patched with ESX350-200806812-BG yesterday evening.

Odd, i thought, and did a CD upgrade of one of our 3.0.2 servers using the CD binaries recently released for 3.5u2 and sure enough the version comes back as VMware ESX Server 3.5.0 build-110268 when a vmware -v is issued.

My question is - why the version difference being reported by VMware ESX and VC 2.5u2 between ESX instances that should have the same revision number - did they upgrade some packages also on the new CDs to warrent a version hike over a 3.5u2v2 patched installation.

If anyone knows, especially VMware folks, please do enlighten us - especially since the VMware customer communications air is still rather murky given the issue this patch was released for, i don't want to find myself holding the bag once again. Mind you, bad code does happen regardless of how stringent the QA process may be (or even beta code with expiry dates) however this entire experience has left me with a bad taste in my mouth - and i personally really like VMWare and applaude what they have accomplished within the last few years - a mere 5 years ago i would have called anyone crazy for claiming the use of VMs in production space. Man, what a paradigm shift in thinking!

Cordially,

Gerson Ricardo

Network and Systems Engineer

Gables Engineering, Inc.

Coral Gables, FL

[Schorschi]

I think, honestly, that this thread even exists proves that VMware build numbering is confusing. Reading this thread will just about generate a headache for anyone but a true techno-geek. We have asked VMware to change this nutty methodology for 4 years, and have been told, frankely to go fly a kite. I don't mind the fact that different build levels can exist, but the fact that VMware allows two identical servers, in reference to function and functionality, to be at different build levels is in sane. Does VMware realize what this does to internal auditing methods and procedures? It makes it almost in possible to validate anything in reference to code levels. We have had to resort to individual file sums to validate key items. This has to be the most customer unfriendly thing VMware does.

[wizdude]

while the patch/build process probably does need to be organised in a better fashion, i think the whole concept of rolling up patches into the 3.5u2v2 media was to prevent a second backlash from people who said "i downloaded and installed the new media, and now I have several hundred MB's of patches to install. why didn't VMware just roll them up into the first image".

i understand and agree that this should not occur - a re-released update should not contain any difference besides the actual bugfix itself. similar to what occurred with microsoft and NT4 SP6 ... they re-released it when they discovered an installation issue and made SP6A.

it probably would have been better to refer to this as "update 3", but then this would have caused more work and grief for people who wanted to update to the latest release, more patch kits, etc.

i think vmware were just trying to release an ISO that had the timebomb and any other immediate patches to provide the cleanest install possible for new users.

[Exwork]

This just reinforces my belief that the whole QA process has some flaws in it.

Having a supposed VMWare employee accusing posters of misleading people, when the VMWare release notes clearly state other patches were also included, makes this even better.

As I'm sure others do, I test updates and patches in a lab before deploying them onto the production servers. Re-releasing an update with a number of addtional patches, as obviously occured here, with anything other than the fix for a critical bug, would invalidate my entire test procedure.

A re-released update with a number of new patches isn't that update anymore. As parent posted stated, a better name for this re-release would be ESX 3.5 U3.

[i4004]

Schorschi/Exwork/All:

Thanks for sharing your experiences. I wonder if its possible to pool

our trouble tickets together in one major Trouble Ticket-like Lawsuit

(obviously not a real lawsuit, but to have a good number of us who have

experienced being shrugged off by VMware due to us solely being one or

two people calling about this at any one time). If we get a good number

of people sending in tickets over this issue, perhaps referencing this

community thread as an example of what this build-versioning confusion

can bring, then perhaps enough momentum will finally come across to get

through to the decision makers in this process.

Even if you don't want to call in to enter a trouble ticket for this,

you can also way enter a help desk request through their help desk

portal here (store account required, but if you're here, odds are you

already have an account..if not please create one):

https://www.vmware.com/support/login.do - once logged in you can enter a

ticket over this build number/versioning fiasco. I'm sure it'll raise an

eyebrow - I mean how can two releases, reportedly the same (according to

VMware) end up with different build numbers?

If entering a ticket is too much for anyone considering joining the

foray, please consider voicing your concern here on this thread (but

really - an electronic trouble ticket would take seconds in the making,

and the end result would benefit us all). I've contacted some local

VMUG pals of mine to do the same and I would ask that if this indeed is

something you would like addressed by VMware, then please send in your

tickets stating that this build number - version problem cannot continue

given the amount of confusion this is causing.

As a VMware customer, product user (engineer), and shareholder, Its

incredible that I have to keep track of our own build numbers using

self-generated md5 hashes on key VMware ESX files spread out all over

the console shell - and like Schorschi pointed out - I'm appearantly not

the only one doing so either . This build number mess smells of being

the brain-child of some committee somewhere - and I state again, we need

crystal clarity now with everything that's going on with our ESX servers

right now, not more obfuscation.

Cordially,

Gerson J. Ricardo

General Network and System Administrator

Gables Engineering, Inc, Avionics Division, Est. 1946

Coral Gables, Florida, 33146

[i4004]

Schorschi/Exwork/All:

Thanks for sharing your experiences. I wonder if its possible to pool our trouble tickets together in one major Trouble Ticket-like Lawsuit (obviously not a real lawsuit, but to have a good number of us who have experienced being shrugged off by VMware due to us solely being one or two people calling about this at any one time). If we get a good number of people sending in tickets over this issue, perhaps referencing this community thread as an example of what this build-versioning confusion can bring, then perhaps enough momentum will finally come across to get through to the decision makers in this process.

Even if you don't want to call in to enter a trouble ticket for this, you can also way enter a help desk request through their help desk portal here (store account required, but if you're here, odds are you already have an account..if not please create one): https://www.vmware.com/support/login.do - once logged in you can enter a ticket over this build number/versioning fiasco. I'm sure it'll raise an eyebrow - I mean how can two releases, reportedly the same (according to VMware) end up with different build numbers?

If entering a ticket is too much for anyone considering joining the foray, please consider voicing your concern here on this thread (but really - an electronic trouble ticket would take seconds in the making, and the end result would benefit us all). I've contacted some local VMUG pals of mine to do the same and I would ask that if this indeed is something you would like addressed by VMware, then please send in your tickets stating that this build number - version problem cannot continue given the amount of confusion this is causing.

As a VMware customer, product user (the virtualization engineer for the company i work for), and shareholder (i like the company/product that much), Its incredible that I -and appearantly others as well - have to keep track of our own build numbers using self-generated md5 hashes on key VMware ESX files spread out all over the console shell - and like Schorschi pointed out - appearantly we're not the only ones doing so either . This build number mess smells of being the brain-child of some committee somewhere - and I state again, we need crystal clarity now with everything that's going on with our ESX servers right now, not more obfuscation.

Cordially,

Gerson J. Ricardo

General Network and System Administrator

Gables Engineering, Inc, Avionics Division, Est. 1946

Coral Gables, Florida, 33146

[jcockroft]

Gerson, Others,

The binaries from ESX350-200806812-BG and from ESX3.5u2v2 are from different builds. Our build system does not guarantee that the binaries generated are identical because the build number is incorporated into the binary. As noted, the md5sum changes. However, VMware guarnatees the end binaries are functionally equivalent. To restate, we did not include any other changes into these builds.

-jason, VMware