Besides the 3 extra files the file "vpx\VMware VirtualCenter Server.msi" also seems to be different. After extracting the msi and running a diff I get the following output:
Binary files vpx\new\!Property and vpx\old\!Property differ
Binary files vpx\new\!_StringPool and vpx\old\!_StringPool differ
The first shows some additional info and seems to only concern some install dialog text, the 2nd one doesn't show additional info.
Since we currently don't have any problems (running VC2.5U1 (84767) with both esx 3.0.2 (63195) and 3.5u1 (82663) hosts I'm not planning any additional repair actions unless vmware support tells me to (opened an incident monday morning to clear up the buildnumbers puzzle).
typo edited by: wally
Since I upgraded my VC 2.5 to 2.5 Update1 (with the correct MD5), I have a pb not described previously on this topic:
if the VitrualCenter service is restarted, all informations about processors are lost for all ESX (3.5 or 3.02) in the summary or in configuration/processor tabs and memory informations are lost in configuration/memory tab. So the cluster composed by these servers have 0 processor and 0 Ghz. To solve the pb, I have to disconnect and reconnect each ESX servers from the VirtualCenter...And informations are back. If the VirtualCenter service is restarted, information disappear again.....Everyone else got this problem?
As of 10AM today, download2.vmware.com at 188.8.131.52 is still pumping out the wrong file, with the 6201... md5 sum. Come on vmware, get it fixed!
And while we wait... why does this keep popping into my head?
"Don't you love farce?
My fault I fear,
I thought that you'd want what I want,
Sorry my dear
But where are the clowns
Send in the clowns
Don't bother, they're here.
Isn't it rich, isn't it queer
Losing my timing this late in my career
But where are the clowns
there ought to be clowns
Well, maybe next year" - Stephen Sondheim
I think VMWare may be at the mercy of Akamai to correct the caches that exist in the cloud.
We need a comprehensive explanation from VMware:
1) What are the correct build numbers??
2) How to verify we have the correct files??
VMware messed this up, they need to continue working on making this right, and to announce loudly and clearly when it is made right.
Very shocking to read this kind of news, makes one wonder...
Thank you, Tom
I believe the better approach is for them to take down the link until they resolve the distribution problem with Akamai. They are compounding the problem every minute they leave it up. As to the best "fix". Rename the file, and redistribute it through Akamai. No need to worry about "bad" cached files if the name changes and they point everyone to the new file.
They could post a "Sorry we messed up" message on the web page.
I just opened a SR referencing this thread, I know some internal vmware employees know about this issue but wanted to get some clarity from support.
Here is what I have from them so far:
Hello Ben Conrad,
There are some areas that haven't been updated yet....Please download the ISO files as they don't have this issue.
Support seems to be taking a down turn with vmware on this one.... My company is starting to second guess their decision...
I sat on the phone saturday for 4-5 hours with this issue, only to have vmware tech support say lets take this up on monday at a specific time that we all agreed upon. Well yesterday, we sat around waiting for vmware tech to call us or email us and nothing. What kind of support is that?
Appears to be a definite black eye here for VMware. Hope they understand this and start fixing things, etc.
Official response from vm support:
"Please download the ISO file as that one +seems +to be correct...we are working on correcting this issue.
Let me know if that answers your question.
Looking forward to your response "
I bolded the interesting wording on this, and will try it next.
I asked them to be proactive and pull the bad link, notify all users that have downloaded it so far, re-release it with a modified name for clarity, and post info on the web page. Of course, I expect nothing to happen.
Updated at 1PM EST. Just spoke with a manager in vm support. He assured me that this has been elevated internally at VMware, to his manager, and at least the level beyond that. Teams are working to resolve, but no real info was given. He seemed frustrated as well, and probably rightfully so, since they get to hear about it first hand. I was able to download the ISO version, and it's MD5 matched, so I uninstalled all of the "bad" versions, then reinstalled from the ISO. So far, so good.
We believe everyone should be able to access the correct bits now.
We have an ongoing ticket with Akamai to check at several edge IPs, but the best way to test a worldwide, distributed system is -- to test it in worldwide, distributed fashion.
Can a few folks try to download the zip file and confirm they are getting the right md5sum, and what IP you got it from? We appreciate the extra help before giving everybody the "all clear" signal at support and here on the community.
We'll start a new thread with an official statement once we confirm this, and I'm sure you may have some feedback for us in that thread. Many people internally are both aware of the situation and are reading these threads, so your comments and suggestions are not going by unnoticed.
Please provide a clear description of what the correct bits are -- what
build, contents, whatever people can use to verify for themselves --
otherwise this snafu will linger on...
Thank you, Tom
I installed incorrect version of VC (upgrade from v3.5) but apart from some troubles with converter and updater plugins not being installed properly everything seems ok. About box shows version 767 for VI and VC. I have to say I do not have HA and VMotion so do not know if it is ok and I did not try creating/deleting/moving VMs but basic day to day finctions seems to be ok.
Now given that should I reinstall? I assume reinstall will require complete uninstall of VC server, client, updater and converter?
Just dowloaded it. Here is the info:
Addresses: 184.108.40.206, 220.127.116.11
Aliases: download2.vmware.com, download2.vmware.com.edgesuite.net
Sorry, Tom -- if you'd just studied the 131 messages in this thread over the last 4 days, you'd know exactly what I was talking about.
This will all get detailed in the new thread, but as Jason says above, this is the correct zip file:
Extracts to 55 files, 13 folders 552,462,397 bytes
Note that the 84872 in the filename is the build of the installer, and the VC installed will have a build number of 84767. This is by design.
The incorrect file had an MD5SUM starting with 6. We identified the root cause and this is the only file that was affected.