VMware Cloud Community
admin
Immortal
Immortal

VMware Infrastructure 3 v3.5 Update 1: Build Numbers and MD5SUM issues and upgrade experiences

Summary

VMware Infrastructure 3 v3.5 Update 1 (VI3 v3.5 U1) was released on April 10, 2008. Over the following weekend, we received reports that there were issues with the upgrade to VMware VirtualCenter 2.5 Update 1 (VC 2.5 U1), a component of VI3 v3.5 U1. As of 11 AM Pacific on April 15, 2008, we have confirmed that those issues have been resolved.

What You Should Do

If you have not yet downloaded the bits, you may do so at your convenience and proceed with the upgrade and installation. We have confirmed that the correct bits are available for download from .

If you have already downloaded the bits, please confirm that you have the correct MD5SUM value for the .zip file before proceeding with installation, as per the details below. If you do not have the correct MD5SUM value, please re-initiate a download, and install from the .zip file that has the correct MD5SUM value. Please remember to clear out your Internet browser's cache prior to re-initiating the download.

Alternately, please download and install or upgrade to VirtualCenter 2.5 Update 1 using the VirtualCenter CD (ISO) image. This ISO file does not suffer from the MD5SUM mismatch issue that the VirtualCenter Zip file has encountered.

If you have already installed or upgraded to VC 2.5 U1, please verify that the .zip file used has the correct MD5SUM value mentioned below. If you do not have the correct MD5SUM value or if you are unsure about the MD5SUM value of the .zip file that you installed or upgraded from, and are experiencing any issues, please call in to VMware Support and open a support request (SR). There are no known issues associated with the VirtualCenter version installed using the .zip file with the incorrect MD5SUM value, but it is highly recommended that the correct .zip file for VC 2.5 U1 be used when installing or upgrading to VC 2.5 U1.

Details

VMware Infrastructure 3 v3.5 Update 1 (VI3 v3.5 U1) was released on April 10, 2008. Over the following weekend, we received reports that there were issues with the upgrade to VirtualCenter 2.5 Update 1 (VC 2.5 U1), a component of VI3 v3.5 U1. As of 11 AM Pacific on April 15, 2008, we have confirmed that those issues have been resolved.

There were two primary topics discussed among the forum posters: one related to build numbers; and another related to incorrect VC 2.5 U1 bits.

1. Build numbers

As documented in the release notes at the correct build numbers are as follows:

VMware Infrastructure Management Installer | 10 APR 2008 | Build 84782

VirtualCenter 2.5 Update 1 | 10 APR 2008 | Build 84767

Note: The VMware Infrastructure Management installer (Build 84782) includes the following packages:

VMware VirtualCenter Server 2.5 Update 1 Build 84767

VMware Update Manager 1.0 Update 1 Build 63965

VMware Converter Enterprise Update 1 for VirtualCenter 2.5 Build 62387

In other words, there are separate build numbers for the VirtualCenter installer and for the VirtualCenter Server itself. This is by design, and should not be a cause for concern. Given the confusion caused by the inconsistency, however, we are looking into ways to simplify the installation experience and better communicate such inconsistencies in the future.

2. VirtualCenter 2.5 Update 1 bits

The MD5SUM value for the correct VirtualCenter 2.5 Update 1 (.zip) file is:

9146aa4743c0a56e37921f62fb898a64

If you have a different MD5SUM value than the above, please initiate another download from and confirm that the .zip file MD5SUM value is correct.

As surmised by several folks on the forums, incorrect bits were uploaded to the content distribution network that we use to support volume downloads. The situation has been rectified and we have confirmed that the correct bits are now available. If for some reason, you are still seeing incorrect MD5SUM values, please let us know by posting on this thread.

We sincerely regret and apologize for the inconvenience caused as a result of this issue. We are taking necessary steps to identify and rectify issues in our release infrastructure processes and systems to ensure that this does not happen again in the future.

Regards,

VMware Infrastructure Product Management

Message was edited by: jasonboche

Appended to the end of the title because the original upgrade thread was locked and now references this thread

Tags (4)
Reply
0 Kudos
21 Replies
java_cat33
Virtuoso
Virtuoso

Thanks for this clarification

Reply
0 Kudos
Troy_Clavell
Immortal
Immortal

great information! Is there a way you can sticky this thread?

Reply
0 Kudos
jasonboche
Immortal
Immortal

Thank you for the update and closure VMware.

great information! Is there a way you can sticky this thread?

The thread is linked to an announcement in the forums so in that sense, there is a sticky that links to the thread.






[i]Jason Boche[/i]

[VMware Communities User Moderator|http://communities.vmware.com/docs/DOC-2444][/i]

VCDX3 #34, VCDX4, VCDX5, VCAP4-DCA #14, VCAP4-DCD #35, VCAP5-DCD, VCPx4, vEXPERTx4, MCSEx3, MCSAx2, MCP, CCAx2, A+
Reply
0 Kudos
admin
Immortal
Immortal

This software doesn't have "sticky" threads, but I have put

announcements pointing to this thread in this community, its parent, and

the main communities.vmware.com page.

Reply
0 Kudos
tlyczko
Enthusiast
Enthusiast

Thank you for posting all this.

We all got new 3.5 license files etc. when 3.5 was first released.

Do we have to get new license keys too??

Thank you, Tom

Reply
0 Kudos
admin
Immortal
Immortal

Tom,

This is an update to the VI3 v3.5 release. No new license keys are involved. Your existing license keys will work just fine.

Reply
0 Kudos
bkhowson
Enthusiast
Enthusiast

I downloaded the early ZIP file. I am having problems with VirtualCenter, the client fails (disappears).

It seems that I have all the correct versions. I could remove and reinstall the whole virtual center, but that will take a while so I want to make sure it is neccessary.

As far as I could tell by comparing the original 'wrong md5sum' zip file to the current one, the ONLY differences seem to be that the wrong one is customized for Dell, i.e., the 'buy now' links when in eval mode go to www.Dell.com. Is there really a reason to uninstall the Dell-link version and reinstall the current one? Are there any bugfixes, etc in the new one that aren't in the Dell one?

Reply
0 Kudos
jasonboche
Immortal
Immortal

Just as an FYI, the original VI 3.5 Update 1 Upgrade Experiences forum thread located at http://communities.vmware.com/thread/138793?tstart=0&start=0 has been locked by VMware and they request all subsequent experiences be discussed in this thread. I'm pointing this out because there was useful information that could be referenced in the original thread that may help direct people.

I have also appended to the end of the subject of this thread to reflect the fact that upgrade experiences are being discussed here per the request of VMware.

Jas






[i]Jason Boche[/i]

[VMware Communities User Moderator|http://communities.vmware.com/docs/DOC-2444][/i]

VCDX3 #34, VCDX4, VCDX5, VCAP4-DCA #14, VCAP4-DCD #35, VCAP5-DCD, VCPx4, vEXPERTx4, MCSEx3, MCSAx2, MCP, CCAx2, A+
Reply
0 Kudos
Natiboy
Enthusiast
Enthusiast

In an effort to troubleshoot the VIC issues I have seen since my VC2.5/ESX3.5 upgrade, I found the following results. All of these were verified after 15 Apr 2008: Notice the inconsistency of the VIC versions from ESX 3.5 U1 and the VC 2.5 U1 in the add/remove programs. 4 Payloads in size and 3 Results in version. This is deeper than the MD5 issue. What gives?

DeploymentSource

Filename

SizeExe(MB)

MD5sum Hash

WinXP 'Add/Remove' Reports

VIC 'About' Reports








VC2.5

Vmware-viclient.exe

26.9

17d176068cb87305d1bf5cd2fbe9be53

2.5.0.64192


64192

VC2.5-U1

Vmware-viclient.exe

28.3

ab442997b7027744c56c12a32e430881

2.5.0.64207


84767








ESX-3.5.0-77234

Vmware-viclient.exe

50.1

0e06d20ea914835bf765c9b8caf3b7c1

2.5.0.64192


64192

ESX-3.5.0-82663

Vmware-viclient.exe

54.3

243c1545d12db556dd53c035e52a93e4

2.5.0.64207


81946

I pulled each of these vics to an xp workstation by downloading them from the web interface of the recently installed system. Why do I need 4 versions of a client? Isn't one VIC client version enough?

Reply
0 Kudos
admin
Immortal
Immortal

Did you do a fresh install of the VC 2.5 U1 build or did you perform an upgrade? If you did an upgrade, then you may want to try uninstalling the VI Client Plugins (for Update Manager and Converter Enterprise) and re-install just the plugins in the VI Client.

Also, it wasn't clear from your post if you installed/upgraded using the Zip file with the correct MD5 checksum. Could you please confirm? I'd recommend filing a support request (SR) if you are still facing any issues so that you can obtain assistance in a timely manner.

There is no functional difference (or difference in patches/fixes) between the "correct" .zip file and the "incorrect" .zip file. The only difference is an XML file that points to an invalid URL in the latter (incorrect .zip file). So, from a practicality perspective, there is no real reason to uninstall the "incorrect version". But for sake of consistency with the “correct version” and to avoid any possible support issues in the future, we recommend that you have the correct version running.

For correcting any installations or upgrades performed using the incorrect .zip file, simply remove the 'customLinks.xml' file from C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\docRoot\client from the VC Server.

Message was edited by: akotian

This is an update to the earlier post. We have confirmed that there is no need to uninstall the VC instance. All that is required is to simple remove the XML file mentioned above

Reply
0 Kudos
Wiks
Contributor
Contributor

Adding my 2cts:

Feeling confident the wrong bits issue was resolved I downloaded the ISO and checked the MD5sum. All checked out so I proceeded to update VC using the autorun install.

License server was updated, update manager, database... All went fine. Hopeful I launched the VI client only to find that I was suffering the same problems I have seen reported in the previous thread.

Moving around in the client I got the same "logfile cannot be found in documents and settings...." errors and just plain exiting of the entire client.

I found that disabling the Update Manager plugin solved the issue. So I removed update manager and reinstalled using the existing database.

This did not solve the problem. I eventually proceeded reinstalling update manager with a re-initialization of the database. I was scared it would re-initialize the entire database but that does not seem to be the case.

Only the Update Manager repository is affected. After this procedure all was fine.

Obviously my baselines were gone but at least all is stable now. I'm going to proceed with updating the hosts to 3.5.1 now.

Reply
0 Kudos
bkhowson
Enthusiast
Enthusiast

The VIC problems that I had traced to libeay32.dll and/or ssleay32.dll issues. Search for these in your system path (which libeay32.dll), and if possible remove them. You can also copy them from the "C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\2.5" directory to "C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher" (VMware support did that to troubleshoot). However, I found that if you want both the webui and vic to work you need to eliminate non-compatible versions (on my laptop, I had a one in "C:\Program Files\Intel\Wireless\Bin").

These are open source libraries (OpenSSL) used by lots of programs. They must have moved to a new version that has breaking changes.

Reply
0 Kudos
Natiboy
Enthusiast
Enthusiast

Thanks Akotian for the reply,

Some clarifications for you. I installed the .iso based installation on all parts individually from the posted links after 15 August 2008: VC2.5, VC2.5U1, ESX3.5, ESX3.5U1 on different systems. Then from the xp desktop I extracted the 'client' from the web interface of each respective system into a local directory on a desktop. Once I had a directory of all 4 versions of the file i reinstalled and uninstalled the client only from those .exe's. The table I produced above is what versions result.

This makes me conclude that in the case of the VIC for 2.5/3.5:

  • The VC2.5 and ESX3.5 installation packages are different by some 23MB (27MB vs 50MB) if you selected the VC 2.5 system for your updated client versus the ESX 3.5 host. This doesn't matter in the end however because the versions report the same.

  • In the case of the 'Update 1' payloads from each of these systems you get 26MB (28MB vs 54MB) of difference in the install file. This results in two versions of the VIC client as reported in the 'About Vic', but the same version as reported in the 'Add / Remove hardware' list.

  • The VIC is not just 'the 2.5 client' when "Update 1" is involved. There must be a reason why the same client payload isn't distributed with the original distributions versus Update 1.

I will generate a ticket, I'm just not sure there is a problem to solve.

Reply
0 Kudos
jasonboche
Immortal
Immortal

I performed another install of VirtualCenter 2.5.0 Update 1 from scratch and confirmed that it does not automatically install the license server along with the other bundle of software (VirtuaCenter Server, Virtual Infrastructure Client, Update Manager, Converter Enterprise, etc.)

The license server must be installed manually by invoking \vpx\VMware-licenseserver.exe

I find this behavior odd since the VIM should install everything.

Noteables:

1. Some users who have been upgrading are seeing that the VIM upgrades their license server as well

2. When I use the VIM to perform my installations, I always choose a custom installation because I don't want all the components installed on the C: drive. I put them on D:, E:, etc.. I wonder if for some reason a custom installation cancells out the license server installation?






[i]Jason Boche[/i]

[VMware Communities User Moderator|http://communities.vmware.com/docs/DOC-2444][/i]

VCDX3 #34, VCDX4, VCDX5, VCAP4-DCA #14, VCAP4-DCD #35, VCAP5-DCD, VCPx4, vEXPERTx4, MCSEx3, MCSAx2, MCP, CCAx2, A+
Reply
0 Kudos
bjselman
Contributor
Contributor

I wonder if there will be an 'amendment' to Update 1 to address the things mentioned? I was going to patch U1 to my 3.5/2.5, but I am reconsidering now.

Reply
0 Kudos
Aketaton
Contributor
Contributor

I'm having the same experience (no automatic License server update when using custom installation path for VC).

I've performed an upgrade from 2.5.0.

Reply
0 Kudos
chumeng
Contributor
Contributor

This is working too.

md5sum VMware-VIMSetup-2.5.0-84782.iso

0b5da72003e5627ae12669c2d43821e5 VMware-VIMSetup-2.5.0-84782.iso

Reply
0 Kudos
benp23
Contributor
Contributor

Why would we want to upgrade and risk downtime? What are the advantages? All I see here are problems. What are the enhancements/fixes provided by the upgrade?

Thanks,

benp23

Reply
0 Kudos
benp23
Contributor
Contributor

In other words, we're running fine on ESX 3.5 64607 and VC 2.5 64192...

benp23

Reply
0 Kudos