vSphere Upgrade: Going to 4.1 (Updated)

Well I had some serious issues going to vSphere 4.1 from v4.0U2. The steps for the upgrade seemed straightforward:

1. Upgrade vCenter Server
2. Upgrade ESX

Well, it was not all that easy.

vCenter Upgrade

When I went to upgrade vCenter it complained about the Guided Consolidation Utility that was installed. So I went to remove it, and the remove failed with all sorts of MSI errors regarding not able to make the necessary transforms. Even a reboot did not fix the problem. I needed to use the Windows Installer Cleanup Utility. Which is no longer on the Microsoft website, so had to find it else where.

Problem 1: Removal of Guided Consolidation  required removial using Windows Installer Cleanup Utility

Once that was removed I had TWO sets of tables, stored procedures, and views defined. This complaint was in the 4.0U2 upgrade but the upgrade completed as is. This time the Installer stopped and wanted me to fix this. Well a bit of searching showed that the KB articles on VMware’s site were just a bit dated (vCenter 2.5 to 4.0 using MS SQL 2005). I did upgrade vCenter from 2.5 to 4.0 but on MS SQL 2008, you would think things would work, but they did not. After several attempts I decided to start over with a new database.

Problem 2: Multiple Schemas, I had TWO sets of tables, stored procedures, and views (or multiple schemas) with no way of knowing what to remove, alter, or keep.

I tried to delete all the duplicate tables, but ended up with missing data. So I restored and tried again trying to Delete just a few tables. I tried to Delete all duplicate Views then modify the schema of all non-duplicate views and stored procedures. But I was still with missing data.

The solution was to start over, which I did not mind doing as the environment is pretty small and allows me to clean up the databases from the upgrade.

Update 1: I also had to reconfigure vCenter to allow my VMs on Private Virtual Networks to migrate. I did this by opening up the Administration -> vCenter Server Settings Dialog, clicking on Advanced Settings and adding config.migrate.test.CompatibleNetworks.VMOnVirtualIntranet with a value of false. No need to reboot the vCenter server using this method

Update 2: VMware Data Recovery was no longer a solution within my vCenter server once I started over, so I had to reinstall the plugin then restart the vSphere Client to once more have VDR as a Solution.

Update 3: I have been using VKernel tools since GetstaltIT Tech Field Day Boston (spring 1010), and the new install of vCenter caused me to have issues with the VKernel Monitoring. Specifically, I had to reattach Capacity Analyzer and the Optimization Pack to vCenter once more. Optimization Pack connected with no issues, but with Capacity Analyzer I had to remove the previous connection and recreate the connection. Then I had to relicense my ESX hosts within Capacity Analyzer. Not until I did all these tasks did these two VKernel products work once more.

Update 4: It was also necessary for me to change the port on which tomcat runs in order for vCenter WebServices to start properly. Edit the file ‘C:Program FilesVMwareInfrastructuretomcatconfserver’. Search for the value 8005 and change that value to be 8006. Save the file and restart VMware vCenter WebServices.

VUM Upgrade

Next was to install/Upgrade VUM and that failed. I kept getting the same authentication error and the installer would stop. The KB articles helped here but did not cover everything. KB1003468 fixed most of the issues but did not comment on the VI 4 Update folder that contained all the old SSL certificates. Once I removed that folder and restarted the upgrade all worked as expected.

Problem 3: “Error 25085 – Setup failed to register VMware Update Manager extension to VMware VirtualCenter Server”, following KB1003468 and removing the VI 4 Update folder solved the problem.

ESX Upgrade

With a little help from VMguru.nl I started my ESX v4.1 upgrade. There are two things that MUST be fixed after the upgrade however, related to the passwords which is covered within the VirtuallyGhetto blog. This is to change the password requirements to use md5 and not DES based encryption for authentication purposes. VMware will soon have a patch for this. Yet, this did not solve my authentication completely. The other issue is that pam_access is now being used, and my administrative local account was not allowed via pam_access after the upgrade. To fix this I had to modify /etc/security/access.conf to allow this user.

Now I am upgraded and will migrate to Virtual Distributed Switches shortly.