April 10 VMware released the first minor update for its flagship product: VMware Infrastructure 3.5 Update 1.
As expected many customers took advantage of the weekend to download the new build and install it.
Unfortunately the early adopters are not reporting a smooth upgrading experience.
The biggest problem is that the bits available are not the ones of Update 1, according to the build numbers: while the website declares a final build number of 84782, the downloaded bits install a version with the build 84767 (a discrepancy confirmed by the MD5 signature mismatch).
The wrong build provided any sort of technical issues to the unlucky early adopters which tried to perform an upgrade: disabled plug-ins, VirtualCenter Client crashes, guest OS templates disappearance and inability to customize then, etc.
Besides a lot of time wasted, the build mismatch also impacted the productivity in some cases: some customers in fact installed the VI 3.5 Update 1 in labs while others put it directly into production environments.
VMware was informed of the problem immediately and invited to download the bits again the day after. Unfortunately the re-downloaded ISOs were still providing the build 84767, causing chaos among users.
The second answer VMware provided clarified that, despite the MD5 mismatch, the available bits were the correct ones. Despite that customers continued to experience crashes and were forced to downgrade to 3.5.0 (which caused a painful mess of different builds for different tiers of the virtual infrastructure).
After the entire weekend VMware has yet to solve the problem while the number of users afftected by the issue grew exponentially: so far the VMTN thread about the topic got 989 visits with 79 replies.
This is already the second time that VMware publishes the wrong build for a production release: before April it already happened in December 2007, when the company released VI 3.5.0. The correct build wasn’t posted online untile February 2008.
Now customers, already complaining for the plethora of different build numbers on any GA release, are afraid that VMware will correct this second error after another two months.
Update: VMware sent us a note to specify that the build numbers mentioned above are not incorrect.
The VI 3.5 Update 1 comes with different build numbers for each component and while the Virtual Infrastructure Management Installer has the GA build 84782, the VirtualCenter itself has the GA build of 84767.
At today VMware is still investigating the issue and thinks it may depend on its content distribution service: Akamai.
Second update: At the end of Tuesday, 5 days after the first incident, VMware finally solved the problem, confirming its error in uploading the wrong bits on the Akamai content delivery system. And with the promise to not offer a third similar experience.