Just got through a rough few hours upgrading to the latest version of the VMWare Virtual Center server product (that was just released yesterday!). I know, right? I’m a glutton for punishment.
Anyway, just wanted to throw some notes up there in case there was anyone else out there who could benefit from the experience I just had.
We have two VCenter servers, both connecting to the same SQL 2005 Database server. With that setup in mind, here’s where I ran into trouble.
Started the upgrade to the first VirtualCenter server, with a full install of all the components including the VMWare Update Manager and the Converter Enterprise Edition.
The database connectivity step failed right away because the SQL Login I was using didn’t have “db_owner” privileges in the MSDB database. This is documented as a necessary permission for SQL Server in the VMWare Installation Guide, but I discovered the requirement in a roundabout way by looking at a SQL Profiler trace of the traffic being sent to the DB from the installer program.
I didn’t realize it needed that permission from a previous installation because we had initially installed VCenter using a local MSDE database.
NOTE: According to the documentation, the MSDB database permission is only needed during installation/upgrade, and can be removed after setup completes.
The next wackiness I encountered was installing the VMWare Update Manager component. It kept failing on install with a cryptic error message. I ran through the setup a few times and realized that the VMUM product has a TCP port conflict with the VirtualCenter Web Access components! We ordinarily don’t install the WebAccess components, but the “suite” installer program apparently automatically installs the Web Access business, silently.
So, Add/Remove programs, and modify the VirtualCenter Server setup to remove the Web Access components, and I was able to successfully install the VMUM components.
After my experience with the first upgrade, I foolishly thought upgrading the next server would be a breeze! The previous dot-revision upgrades for VC 2.0 were completely painless, so I had high expectations.
Little did I know that because of the SQL jobs that are created by the installation process (can anyone confirm that those jobs are part of the database install in 2.0?), there would be a naming collision and it would cause the database upgrade to fail.
Quickly reading through the DB upgrade log (found in c:\documents and settings\<username>\Local Settings\Temp) revealed the problem.
Luckily, we have two SQL 2005 databases in production (and remember, I had backed up the VC 2.0 databases before performing the upgrades). Restored to the second SQL 2005 database server, re-ran the installation routines (skipping the VMUM install!), and everything ran without a hitch.
Anyone else having some troubles upgrading? Next steps for the environment are to plan the ESX Server upgrades to v3.5! Hopefully those won’t be as painful.