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

[Ken_Cline]

Moved to ESX 3.5 forum

Ken Cline

Technical Director, Virtualization

Wells Landers[/url]

VMware Communities User Moderator

[jesse_gardner]

Just a guess, but they did release a bunch of other monthly patches yesterday or today, and perhaps those were included in the new ISOs. My Update Manager downloaded a bunch of new patches today, and using that, my hosts are 110268 also.

[i4004]

You are indeed, correct, though Ive never seen a company roll up patches to whats supposed to be a fix for major release like that. The added 8/13 patches should have stayed away from the 3.5 u2v2 release - they just should have fixed the issue without introducing new code that hasnt had a chance to be tested though companies QA processes. I know im pissed. Even the 3.0 to 3.5 installer deport as these new untested patches, and after the 3.5u2 August 12 bomb snafu i imagine we're ALL going to wait a little longer than we would have otherwise before before installing any patches for anything less than some specific critical issue that affects our enterprises.

Very odd to sneak new code like that, very odd indeed. I wonder if something was vasty in the need of repair that they included these patches into the main 3.5u2v2 stand alone upgrade binaries AND iso.

Gerson Ricardo

[admin]

Hi Gerson,

This is the long standing vmware -v reporting. vmware -v report the build # of the vmx RPM. vmx RPM was delivered in the express patch and then again in the reissued 35u2. And hence it reports different version #s.

For detailed build number information for VMware ESX 3.5 and ESX 3.0.x hosts, please see KB 1001179.

Thanks.

MJ

[admin]

Hi Gerson,

More specifics about the question you raised:

1. Each software build produces a unique build#.

2. We first delivered an express patch, which came with its own build #.

3. We then delivered U2 Refresh, which came with its own build# too.

4. We are trying to move away from the build# scheme to prevent any confusion to customers.

Thanks,

MJ

[i4004]

MJ,

So if im to understand your explanation correctly there is NO technical differences between the fixed ESX 3.5u2v2 "patched" CD listed as version 3.5.110181 and the CD released of ESX3.5u2v2 version shown as 3.5.110268? Or does the CD binaries listed as build 110268 ALSO contain the August 13 patches listed in your downloads page, as the last patch is shown to also be 110268 - that my confusion - as both the ESX 3.5u2v2 CD and the last patch listed for the 8/13 release have the same build number is it safe to think that they're included the CD re-release of ESX3.5u2?

Thanks,

Gerson

[admin]

Hi Gerson,

I think embedded in your message are the following two questions:

1. Is the "fix" in the Express Patch, ESX350-20086812-BG (build 110181), contained in the ESX 3.5U2v2 ISO (build 110268)?

The answer is yes. The changeset in ESX350-20086812-BG is in the ESX 3.5U2v2 ISO.

2. Are all patches on the download page with the "8/13" date on the 3.5U2v2 CD?

The answer is yes. ESX3.5 U2v2 contains all released fixes as of 8/13.

Pleaes let me know if you have more questions.

Thanks,

MJ

[stvkpln]

What I think the question is, is the following: Is there any difference between ESX 3.5 U2 (7/25/08) + the express patch vs. ESX 3.5 U2 (8/13/08), and the answer, I believe, is no. The 8/13 patches were a re-released set of patches to take hosts pre-U2 to U2, and replaced those that were released on 7/25/08. Due to the fact that each build process produces a unique build number, the express patch takes existing U2 hosts (that were patched/build based on the content released on 7/25/08) to build 110181, while the updated patches would take any system (either pre-U2 or already at U2) to build 110268. I don't believe it's necessary to take any existing 3.5 U2 systems to 110268 unless there is a preference for consistency in build numbers.

Hope that helps!

[SimonHuizenga]

now i am confused,

when i update a 3.5u2 fixed (build 110181) to 13/8 (13 patches) i have the same build as the new released iso (build 110268).

Are the patches of 13/8 embedded in the new iso?

[i4004]

Sadly, that is exactly what i found out. All the "new" August 13th 2008 patches released (circia several hundred MB worth of ipdated packages which include what you see in the attached Excel file)..

So so answer your question simply: yes - the added patches that VMware released on 13-8-2008 are imbedded in the base installation media and also in the stand-alone 2.x --> 3.5u2v2 zip/taball file, heck even the 3.x --> 3.5u2v2 zip file too. Highly suspicious.

It would seem that VMware was somewhat desperate to incorporate these patches into the ESX 3.5u2v2 base binaries for installation and upgrade versions for whatever reason = would any VMware representative care to elaborate why ESX 3.5u2 wasnt simply fixed with the time bomb patch which left it at build-11081 and leave it there at that as opposed to silently slipstreaming so many patches (over 900mb! worth of QA required!); especially now that all VMware updates will be going the highest possible level scrutiny and QA testing given the August 12 time bomb fiasco we've all grown to know and love so well?

Cordially,

Gerson Ricardo

General Network and Systems Tinkerer

Gables Engineering, Inc (est. 1946)

www.gableseng.com

[i4004]

Sadly, all the "new" August 13th 2008

patches (taking your ESX 3.5u2v2 released along with the new base binaries listed as 8.13.2008 with a build number listed as 110268

So so answer your question simply: yes - the added patches that VMware released on 13-8-2008 are imbedded in the base installation media

and also in the stand-alone 2.x --> 3.5u2v2 zip/tarball file, heck

even the 3.x --> 3.5u2v2 zip file too. Highly suspicious.

It would seem that VMware was somewhat desperate to

incorporate these patches into the ESX 3.5u2v2 base binaries for

installation and upgrade versions for whatever reason = would any

VMware representative care to elaborate why ESX 3.5u2 wasnt simply

fixed with the time bomb patch which left it at build-11081 and leave

it there at that as opposed to silently slipstreaming so many GA and security patches

(over 900mb worth of extra QA required!) and leaving it at build-110268. VMware could not have picked a worse time to silently slipstream these patches without letting userland know beforehand (or at least offering build-11081 base binaries as well) this being true especially now that any wand all

VMware updates will be going the highest possible level scrutiny and QA

testing given the August 12 time bomb fiasco we've all grown to know

and love so well?

Cordially,

Gerson Ricardo

Network and Systems Tinkerer

Gables Engineering, Inc (est. 1946)

www.gableseng.com

[i4004]

Diz,

Thanks for your input - it does give something else to consider other

than just what may perhaps seems obvious to some - including me - that

the patches were included in the final ESX3.5u2v2 builds). However, if

that hypothesis is true then running esxupdate should detect all the

patches in the August 13 patch set as 'needed/required' and proceed to

install them, right?

It just seems so highly coincidental that both the re-released 3.5u2

(version 2) base binaries build AND the final stand-alone patch released

on 8/13/2008 are both seen as build-110268.

Would there be an answer to the latter query on why the re-released

3.5u2 and "unrelated" patch share the same build number?

Thanks,

Gerson

[i4004]

Mjlin,

Thanks for partially answering my questions, Mjlin, (sorry - my kid

brother watches Dragon Ball Z and there is a character there called

"Majiin Buu and for whatever reason your name reminds me of him, but I

digress, with my sincerest apologies....)

My added questions pertain to why VMware technical support decided to

add new code to an already shaky patching situation.

When we went over the install code for the new patch released as "

ESX350-200806812-BG - August 12 time Bomb Issue for U2" which after

installed left us at "VMware ESX Server 3.5.0 build-110181" as per the

results of both our Virtual Center Server/Client systems AND from the

results of the actual ESX 3.5 server when you run "vmware -v" from the

console shell, we expected binary parity with the released base CD and

stand alone upgrades ESX 3.5u2v2 versions.

It clear by your answers that it isn't a build number

misrepresentation/coincidence as suggested in this thread, but that

these new and untested patches (untested by ANY organization using the

CD/standalone media depot) are included in your base binaries that

technically should only have the original ESX3.5u2 binaries plus the

"ESX350-200806812-BG - August 12 time Bomb Issue for U2" patch and

nothing more, leaving the final gold release build at build-110181 as

opposed to grouping a series of userland-untested patches into your

final installation media for ESX v3.5u2v2.

Yes I know that you can technically use the patches to update your

existing test servers to the latest build, however you no longer

provide just the original ESX3.5u2v1 or v1+hotfix only patches to have

us (or any other organization) test/validate these patches individually.

Personally I think this was an oversight of some kind, or Vmware took

advantage that it had to re-release 3.5u2 to include hundreds of MBs of

drivers, general, and security patches. Is there any reason why Vmware

took this "shortcut" to releasing these patches in this manner?

Cordially,

Gerson J. Ricardo

General Network and System Administrator

Gables Engineering, Inc, Avionics Division, Est. 1946

Coral Gables, Florida, 33146

[Exwork]

Hm. I guess this explains why the upgrade package is 1.5 GB, when the download page says:

Latest Released Version: 3.5 Update 2 | 08/13/08 | 110268 | 596 MB

Very suspicious.

[jcockroft]

Gerson,

Thank-you for this correspondence. However, the conclusions that you presented are not correct. Readers of this thread may be mislead by your comments and therefore I would like to clarify. ESX 3.5u2v2 was built from the exact same code base as ESX 3.5u2v1 with the exception of a single change to exclude the time bomb. ESX350-200806812-BG product expiration patch included only this single change set as well. Your conclusion that ESX 3.5u2v2 included other changesets including "drivers, general and security patches" is not correct. As well, the comment that we released "untested patches" is also not correct.

ESX 3.5u2v1 includes all the previous patches released on the ESX 3.5 line plus small enhancements. We did not release a new patch after U2 was released, until the August 12 product expiration patch. We did not attempt to stripsteam other fixes, drivers or additional changesets into U2v2 or 6812-BG patch. Our next patch release is schedule for the first week of September. At this time we will introduce new fixes beyond U2 and the product expiration fix. To restate, ESX 3.5u2v2 included only a single change set difference between the ESX 3.5u2v1 and v2. That changeset was to remove the product expiration code.

-jason, vmware.

[Exwork]

Is that your final answer? I'm seeing differently. If I compare md5s from the RPMs inside the install media, I see a different story.

esx-3.5.0_Update_2-103908.iso is the original ISO I download before the timebomb occured.

esx-3.5.0_Update_2-110268.iso is the newly released ISO from a couple days ago.

To provide a specific example, look at the MPT SCSI driver update.

We've got 1 MD5 for the original timebombed build, and a different one in the fixed build. We also have the same md5 in the individual patch as in the fixed build.

If nothing was added into the fixed build other than the timebomb fix, then I shouldn't be seeing a different md5 for some drivers that had their own individual patches.

Patch ESX350-200808213-UG: Update to the MPT SCSI Driver?

esx-3.5.0_Update_2-103908.iso f72f6bd4eaf81d3da33244c37ebe91fa VMware-esx-drivers-scsi-mptscsi_2xx-350.2.6.48.15vmw-103908.i386.rpm

esx-3.5.0_Update_2-110268.iso dafb317e38bc95af58607379df18b344 VMware-esx-drivers-scsi-mptscsi_2xx-350.2.6.48.15vmw-110268.i386.rpm

ESX350-200808213-UG.zip dafb317e38bc95af58607379df18b344 VMware-esx-drivers-scsi-mptscsi_2xx-350.2.6.48.15vmw-110268.i386.rpm

Patch ESX350-200808210-UG: Update to VMware-esx-drivers-net-ixgbe?

esx-3.5.0_Update_2-103908.iso 8bfc49c589370f48130bbd9abae23bea VMware-esx-drivers-net-ixgbe-350.1.0.0-103908.i386.rpm

esx-3.5.0_Update_2-110268.iso 878eebe99be917126dd66ac120a11d91 VMware-esx-drivers-net-ixgbe-350.1.0.0-110268.i386.rpm

Patch ESX350-200808211-UG: Update to VMware-esx-drivers-net-tg3?

esx-3.5.0_Update_2-103908.iso 23f7789711dfa2595972ab676986ba74 VMware-esx-drivers-net-tg3-350.3.81c.1vmw-103908.i386.rpm

esx-3.5.0_Update_2-110268.iso 2f9a677ef022795d3dd771f49a059ecf VMware-esx-drivers-net-tg3-350.3.81c.1vmw-110268.i386.rpm

Patch ESX350-200808203-UG: Update to VMware-esx-backuptools?

esx-3.5.0_Update_2-103908.iso b4ff621616899f22ad9b5a91931ec357 VMware-esx-backuptools-3.5.0-103908.i386.rpm

esx-3.5.0_Update_2-110268.iso 8db65b947a968e7596da1983420792aa VMware-esx-backuptools-3.5.0-110268.i386.rpm

[i4004]

Thanks for responding, Jason. If possible, then, can you explain the build system? Here is where I, and others in our local VUG detect somewhat of a difference from what you've mentioned. After installing the hotfix for the timebomb patch we end up with the result of vmware -v being:

VMware ESX Server 3.5.0 build-110181

After this point, and on this same server i create a local depot containing all of the patches released on 8.13.2008 (re-released, perhaps? - Are these the patches previously released on 7.25.08 and somehow rehashed?) Once i run esxupdate on this same server that previously had ESX 3.5u2 plus the hotfix (again, the ESX instance reporting build-110181) all of the patches listed and shipped August 13th 2008 get installed. The last of these patches, ESX350-200808201-UG-UPDATE also gives a build version of VMware ESX Server 3.5.0 build-110268 once all 900+ Mb of patches get installed.

I would certainly like to know if the binaries are the same ( 3.5u2v1 + timebomb-hotfix = 3.5u2v2 ) then why does:

a) Why ANY patches get validated and much less, validate enough to get installed on your have a plain vanilla 3.5u2v1 + timebomb patch .

b) If you do have binary parity between the versions you list ( if the hotfix-upgraded version of VMware ESX Server 3.5.0 build-110181 = VMware ESX Server 3.5.0 build-110268 installed from media or from depot) then would someone kindly explain to me how this build system works since obviously bigger bumbers does.

c) Furthermore if they (110181 + 110268 = same ) are indeed the same binary data/ESX instance then is it possible that its a coincidence that the last ESX build for the last patch applied to a 3.5 installation deport is the same as the CD/DVD media build done on a fresh install using the newly dowloaded CD/DVDs?

Thanks again for your time in clarifying this higly disturbing issue.

Cordially,

Gerson J. Ricardo - Perez

Gables Engineering, Inc est 1946

Flight bus systems and panels since before 1001100011's

Network, Systems, and Virtualization Administrator

Server, Storage, and even the Kitchen Sink Department

[i4004]

Exworks,

Dude! Your entirely correct - kudos to your Holmes like observation - this should have been the first thing i should have looked at as opposed to simply comparing easily manipulated version numbers.. It was cumbersome but after running a comparison o the ENTIRE set has been touched and ZERO md5 hashes match- i mean they would have to modify the contents of the binaries included in those compressed libraries - a simple literal 'touch'simply wouldnt do it - you would have to add or remove to the binary/ascii lvl 5 files for those hashes to be different somehow. An excellent find!

However the ESX waters which house customer confidence which was becoming clearer after the recent and well known "RC/Beta expiry code problem which somehow got into the final build (ESX 3.5u2v1) requireing an emergency hotfix snafu" is once again getting somewhat darker.

In this thread alone we havea few chaps claiming to be VMware fellows with nice little 'three windows' icons next to thier names stating different things concerning this versioning thing - differences to what amounts to heresy as no proof is offered anywhere for anything said - no 'check this md5 hash' or 'look at this build article in the kb' - nothing. Don't get me wrong, im glad the answered back something as opposed to staying quiet, but it does seem that even internally there is a bit of a communications issue.

Exworks - my hat off to you - thank you for your time and effort! Rest of the VMware crew - please come clean with these added/changed files that are CLEARLY differnt due to thier md5 hashes demonstrating it without a shadow of a doubt. Furthermore please give some formula for understanding these build numbers. Honestly, we in the Enterprise (no not the ship - the hundreds upon hundreds of ESX installations on everything form machine using old Conner 9.1GB boot drives to the latest Dell test server running those swanky nehalem 32nm test processors using no FSB and DDR3 in tri-access mode the need is clear across the board:

We need crystal clarity now - not more obfuscating behavior. As a VMware customer who beta tested your workstation software before people outside the mini-mainframe world new what 'virtualization' and 'partitioning' or a processor was (as if this matters to VMware as a whole...another one born every minute, eh?):

Please, please, please be up front about what's going on - there may be internal reasons that sound wonderful on why to not disclose issues now (to save face, prop us time to fix this or that, waiting on team/contractor X to have this feature mature, etc), which in the short run may buy you some time until, for instance, those "early september' patches get released - but the net effect is that your reputation suffers. As much as you want to be seen as the Microsoft of the virtualization world, of which you are now, you certainly don't want to have thier reputation(tm) in the industry.

Thanks for hearing me out - i doubt it'll change anything anywhere in any of your decision making or QA processes but one can only hope a seed somewhere will be planted (i.e., the old adage of the falling seeds - though its not meant for this it applies wonderfully - those that identify it shhh - it works here too "...one seed fell on hard soil and withered ( the hardened exec that isn't changing squat for anything that remotely threatens his 'bonus' now just months away..); the other seed which fell in weeded land as was eaten by the birds ( the conscientious person who half-heartedly tries to say or do something positive but end up standing really for nothing so they end up falling for anything - right by others perhaps its also money, or even lack of motivation, or the sad new American plague - laziness, etc ... ), and lastly the seed that hopefully is you, dear VMware employee/moderator/reader ( heck even you Jason, or how about you Majiin Buu? ), may the seed that falls onto fertile soil which grows and strengthens your Company, your customer relationships, and in then end your bottom line - may you be that seed that heralds the clarity in communications that so many companies lack buy need desperately nowadays to not only stay afloat, which were all certain that VMware is going to do, but just how it carries out that mission - that's what remains to be seen.

Cordially,

Gerson J. Ricardo - Perez

Gables Engineering, Inc. ~Coral Gables, FL, 33146

Triplicate Flight Bus Systems and Instrumentation Panels since before 0b11110011010's

Network, Systems, and Virtualization Administrator

Server, Storage, and heck, even the Kitchen Sink Department

[Exwork]

Actually, I just noticed that the VMWare release notes actually say that other patches are included in that release.

http://www.vmware.com/support/vi3/doc/vi3_esx35u2_vc25u2_rel_notes.html#patches

-

---

New Patches in Update 2 (13 AUG 2008 | Build 110268 )

• ESX350-200808201-UG: Security and other updates to Multiple RPMs, Including VMkernel, Service Console, and hostd

• ESX350-200808202-UG: Update to ESX Scripts

• ESX350-200808203-UG: Update to Backup Tools

• ESX350-200808205-UG: Updates to CIM and Pegasus

• ESX350-200808206-UG: Update to vmware-hwdata

• ESX350-200808207-UG: Update to VMware-esx-lnxcfg

• ESX350-200808209-UG: Update to VMware-esx-srvrmgmt

• ESX350-200808210-UG: Update to VMware-esx-drivers-net-ixgbe

• ESX350-200808211-UG: Update to the tg3 Driver

• ESX350-200808212-UG: Update to the MegaRAID SAS Driver

• ESX350-200808213-UG: Update to the MPT SCSI Driver

• ESX350-200808214-UG: Update to the QLogic SCSI Driver

• ESX350-200808215-UG: Update to the Emulex SCSI Driver

• ESX350-200808217-UG: Update to Web Access

• ESX350-200808218-UG: Security Update to Samba Component of Service Console