jasonboche
Immortal
Immortal

VI 3.5 Update 1 upgrade experiences

I upgraded VirtualCenter 2.5.0 to 2.5 Update 1 today (using SQL Server 2005 SP2 back end).

Observations:

1. The license server installation/upgrade is still not called as part of the autorun.exe as all other VI components are (VC server, VC client, VC Update Manager, VMware Converter for VC). The license server installation/upgrade must still be performed as a separate step at the very beginning.

2. SQL back end users are no longer allowed to use the SQL Server 2003 ODBC driver packaged with Windows Server. You must now download and use the SQL Native Client driver and rebuild your DSNs using this driver. Available at: http://www.microsoft.com/downloads/details.aspx?FamilyId=50b97994-8453-4998-8226-fa42ec403d17&Displa...

3. VMware took the feedback of all the database upgrade issues being had with the release of VC2.5.0. Helpful screens now guide us to the correct database upgrade permissions referencing the applicable VMware KB articles. Furthermore, if by chance you grant your VirtualCenter SQL account the sysadmin role to SQL server, the upgrade picks up on this and presents you with a warning message that a new parallel set of database tables will be created rather than upgrading the existing infrastructure. Failure to correct this situation will essentiall result in losing your datacenter after the upgrade is complete.

4. Database upgrade completed without any issues.

5. Once completed, Help|About reflects VIC and VirtualCenter versions 2.5.0 build 84767. Why not 2.5.1? Why is the incorrect build number of 84767 shown instead of what's listed on VMware's website build 84782






[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+
0 Kudos
157 Replies
v01d
Enthusiast
Enthusiast

I upgraded friday morning and have had zero problems.

1. VC 2.5 to 2.5u1 via ISO

2. Per the release notes I unistalled the VI plugins via the control panel.

3. I also uninstalled the VI client as well although I could have used VI update at this point

4. I reinstalled VI client and installed the updated plugins

5. I updated each of the ESX hosts via update manage

I haven't experienced ANY issues with the updates.

VC = 84767

VI = 84767

ESX = 82663

Update Manager Plugin = 1.0.0.63965

Enterprise Converter Plugin = 4.0.0.62387

Fully automated DRS cluster, no vmotion issues.

0 Kudos
BryanMcC
Expert
Expert

Wow.. They must have just changed it.. I downloaded 2 hours agao with the 6***** md5sum then just downloaded again and got the right one (9***).

Help me help you by scoring points.

Help me help you by scoring points.
0 Kudos
jasonboche
Immortal
Immortal

Wow.. They must have just changed it.. I downloaded 2 hours agao with the 6***** md5sum then just downloaded again and got the right one (9***).

I don't think we don't know what the right one is until VMware draws a conclusion on our experiences and their findings and tells us.






[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+
0 Kudos
jamieorth
Expert
Expert

Ok, so what to do? Just wait? My company has 2 hosts at 3.0.1, 42829 and 3 hosts at 3.0.2, 52542 and our VC is 2.0.2, 50618. We have a SQL 2005 backend.

0 Kudos
kellino
Enthusiast
Enthusiast

I have a new theory that I had the correct bits from the start......

I have experienced the following symptoms:

  • VC client closes without warning, after opening a console window

  • VC client complains that a VPX log file is in use (this is a popup message and it appears to let us keep working when it happens).

  • VC client seems slower upon initialization.

  • I reconfigured HA on our hosts and vMotion is now working.

The biggest show stopper was vMotion, but reconfiguring HA fixed that. We still have some client anomolies that are "inconvenient" but they don't prevent us from working.

Maybe the reason the MD5 matched was because we did have the correct build after all?

0 Kudos
BryanMcC
Expert
Expert

I agree... I think that a "burn in" time is needed for the software

update releases.. I will watch the forum before I move my files to

permanent location.

Help me help you by scoring points.
0 Kudos
BryanMcC
Expert
Expert

Yes... Just wait.

Help me help you by scoring points.
0 Kudos
admin
Immortal
Immortal

We have verified to date:

  • Build 84782 Posted on the VC 25 Update 1 is the correct build number for the installer package.

  • The correct zip file md5 checksum is 9146aa4743c0a56e37921f62fb898a64 The correct zip file size is 456,277 kb.

  • These are what are posted on the Web page.

  • The build number for VirtualCenter, post installation is 82767. (See the release notes)

All of our tests are getting the right md5sum, so we suspect an issue with our content distribution network.

We are currently flushing our Akamai caches worldwide, but this can take up to 4 hours.

If you have downloaded a file with the incorrect md5 (6*), can you tell us:

  1. When did you download it, and what is the IP address of download2.vmware.com you downloaded from?

  2. Were you using any sort of download manager and/or accelerator?

If you did get an incorrect download, please try again in a few hours, say 7pm pacific (UTC - 7 hours), and let us know if you are not getting the correct md5sum.

If you downloaded the ISO or the correct ZIP file, and you are having problems, please file an SR via your normal channels. Eric and the team of friendly escalation support specialists are reading this thread and standing by to look at your logs.

When we are more certain we've identified the problem or that people are no longer getting the wrong file, we will let everybody know with a more official statement. Again, in the meantime, you can help us by doing an nslookup on download2 if you got the wrong md5sum, and if you have installed the update and are having problems, filing an SR normally. We're very sorry for the inconvenience this has caused you, and appreciate everyone reporting here on the problems you've had.

0 Kudos
beckhamk
Enthusiast
Enthusiast

John - I was feeling bored so i gave this awhirl to give you guys a hand.....

I just now 7:25pm EST downloaded the VC update1. File size in windows explorer is 452,243kb just downloaded through IE6 on our w2k3 server. The has still doesnt match.

IP from ping of download2.vmware.com is:

C:\Documents and Settings\Administrator>ping download2.vmware.com

Pinging a1534.d.akamai.net http://72.247.238.154 with 32 bytes of data:

Hope that helps!

0 Kudos
dmanconi
Enthusiast
Enthusiast

Just tried now from Auckland, New Zealand (not sure of time difference etc)

But the wrong files was still coming down.

Ping to download2.vmware.com goes to a1534.d.akamai.net http://60.234.9.119

Using IE7

Cheers

David

0 Kudos
stvkpln
Virtuoso
Virtuoso

Here's a new one: I just grabbed the zip right now, and the hash was, in fact, correct! So was the file size (attached the output from WinMD5). When I log into the VI Client, the build I'm getting for both server and client is 84767..... Files were downloaded about an hour ago.... Also, download2.vmware.com -> a1534.d.akamai.net (66.216.46.83). I'm still not sure why the installer build is one rev and the actual post install build is another. That's, at best, a very confusing situation and frankly, it shouldn't be happening.

-Steve
0 Kudos
jasonboche
Immortal
Immortal

>I'm still not sure why the installer build is one rev and the actual post install build is another. That's, at best, a very confusing situation and frankly, it shouldn't be happening.

Agree. VMware has committed to explaining the build numbers much more clearly in the future.






[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+
0 Kudos
admin
Immortal
Immortal

I'm still not sure why the installer build is one rev and

the actual post install build is another. That's, at best,

a very confusing situation and frankly, it shouldn't be happening.

You have the correct files. From the release notes:

VMware Infrastructure Management Installer | 10 APR 2008 | Build 84782

VirtualCenter 2.5 Update 1 | 10 APR 2008 | Build 84767

Product management is reading this thread and the feedback, so I hope we can provide more clarity about what's going on next time.

Thanks for checking the IPs. We should see the Akamai network correct its caches over the next hour. For instance, Jason's getting the wrong file at home, but the right file at work now.

0 Kudos
jasonboche
Immortal
Immortal

It's Monday evening and I now have the benefit of having both the "correct" .zip file and the "incorrect" zip file. My curiosity was killing me so I decided to extract both .zip files and analyze the differences in bits using a handy tool called "Beyond Compare 2" which will perform file/directory comparisons and clearly show differences between the two.

Here's what I found:

The correct .zip:

VMware-VIMSetup-2.5.0-84782.zip

456,277KB

Extracts to 55 files, 13 folders 552,462,397 bytes

MD5SUM: 9146aa4743c0a56e37921f62fb898a64

The incorrect .zip:

VMware-VIMSetup-2.5.0-84782.zip

452,243KB

Extracts to 58 files, 13 folders 552,464,428 bytes

MD5SUM: 6201bd703a932750ca2b4b9fe68996d8

The "incorrect" .zip file has 3 extra files in it that the "correct" .zip file does not have:

\vpx\customLinks.xml 206 bytes dated 3/31/08

\vpx\VMPartnerCustomize.cmd 403 bytes dated 3/29/08

\vpx\VMPartnerCustomize.vbs 1,422 bytes dated 3/29/08

The difference in the MD5SUM bits is not a matter of corruption. It's a difference of 3 extra files.

Another difference is that all the files in the "incorrect" .zip have a time stamp with a 2 hour difference compared to the "correct" .zip. It's as if the "incorrect" .zip file was compiled and zipped in the GMT -6 time zone and the "correct" .zip file was compiled and zipped in the GMT -8 time zone.

Looking at the contents of the 3 extra files, it looks like the Akamai cache was housing an "incorrect" .zip file meant for VMware Partners (Dell is mentioned) that was never meant to see the light of day but accidentally did.






[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+
0 Kudos
davidbarclay
Virtuoso
Virtuoso

Hi Guys,

I've got some of the problems described, but figured another me too post wasn't too useful. However, to help with the testing...

I've just downloaded "VirtualCenter as a Zip file" and got download2.vmware.com which resolved to a1534.d.akamai.net http://72.247.247.161

9146aa4743c0a56e37921f62fb898a64 - it matches!

Now to try and fix the mess I created in the lab by installing the broken one Smiley Sad

Dave

0 Kudos
RParker
Immortal
Immortal

> hosts are still at 3.0.2), able to deploy vm's from customized templates, vi client is not crashing, no issues with remote console connections

Same here, no problems. I actually like the new VC, it's much better than before, I don't konw why so many other people are having problems, ours is absolutely perfect.

0 Kudos
jpoling
Enthusiast
Enthusiast

I just downloaded the file and it has the following (I think wrong) MD5SUM:

6201bd703a932750ca2b4b9fe68996d8

The download site resolved as follows:

Name: a1534.d.akamai.net

Addresses: 96.6.126.49, 96.6.126.41

Aliases: download2.vmware.com, download2.vmware.com.edgesuite.net

0 Kudos
davidbarclay
Virtuoso
Virtuoso

I've reinstalled VC Update 1 (the correct MD5), after doing a full uninstall and even recreating the VC database (it's a lab). It seems to behaving better now...however, doing one thing breaks the client without fail.

Can I ask someone who has done the upgrade, or a fresh install, who thinks it's working fine to click on "Configuration" -> "Licenced Features"?

Soon as I do that, the VC Client locks up and a few minutes later I get time out messages, then again again again until I kill the process.

Anyone?

Dave

0 Kudos
kellino
Enthusiast
Enthusiast

Not having that issue here.

So far the only issues in a few days of use are a couple popups about a VPX log file in use and one time it closed itself without warning.

We didn't modify our license server version yet.

0 Kudos
francois_tiers
Enthusiast
Enthusiast

For the build response :

VIM is build 74782 et VC is build 74767

look here : http://www.vmware.com/support/vi3/doc/vi3_esx35u1_vc25u1_rel_notes.html#patches

0 Kudos