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 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.
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
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:
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.
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
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 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?
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.
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?
WinXP 'Add/Remove' Reports
VIC 'About' Reports
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?
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
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.
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.
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.
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.
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?