vSphere Upgrade Saga: 6.0 Upgrade through SRM

There are many steps to the upgrade of vSphere, as outlined by KB Article 2109760, with the steps for my environment starting at step 4 (vCNS). However, before I could start my upgrade, I had to upgrade any third-party systems first, as well as to upgrade any Microsoft Windows Servers. Everything went fine for vCNS, View Composer, and View Connection Server. However, problem creep started with the View security server (not really on the list, but if you update the Connection Server, you have to upgrade any security servers at the same time).

The first problem I faced was the need to redeploy my Horizon View (steps 5–6) DMZ vCNS (step 4) Edge appliance. Yes, redeploy: a reboot would not fix the problem. The VMware Tools daemon would not start, which would keep VIX from working, which keeps the firewall from being updated. A redeploy fixed this problem.

The next problem was with vCenter (step 7) itself. First, you MUST read the documentation. Do not try to do this if you have not read the upgrade documentation. Even so, it took me three times to complete the upgrade. I believe that there were several issues, which I addressed using the following:

Eventually, I figured it was a drive issue, as in the CD-ROM had to be the D: drive and not an E: drive, or it was a disk space issue. I ended up using my Windows 8 Fusion VM, so the ISO is on D: drive and has lots of spare disk space. So, I am not sure which was the real culprit.

Then, I had to “resync” vCNS, vLI, Veeam, etc. with the new vCenter 6 due to certificate issues. Eventually, I need non-VMware produced certificates—getting there.

vCenter Operations 5.8.4 would not resync, but I planned on upgrading and so did that instead using instructions at www.settlersoman.com/how-to-migrate-vmware-operations-manager-5-8-x-to-vrealize-operations-manager-6-0/. The migration step worked just fine. Since I did not properly set the IP address of the vRealize Operations (vROPS) 6.0.1 (step 8) instance, I had to do this step two times, which was fine, as the migration works regardless. Resync just took deleting the migrated instance of vCenter connector and adding in a new one with the proper credentials.

For vRealize Orchestrator (vRO) (step 8), I had to reset the root password. I found the following to help with this: https://tournasdimitrios1.wordpress.com/2011/01/22/hack-the-password-protected-single-user-mode-on-linux/. This is one reason why vCenter access should be seriously restricted! Console access can cause all sorts of issues. Actually, all my VAMI-based virtual appliances had expired passwords. Some allow you to log in as root using the expired password, but then you need to change it. vRO did that, but I mistyped the password and did not know the keys. The method I found allowed me to use pam_tally2 to clear any failed login attempts as well as to reset the password.

VMware Data Protection (VDP) (step 8) required following KB Article #2111900 first to allow the proper SSL ciphers to work with modern browsers.

vSphere Replication (VR) (step 8) required me to use KB Article #2112332 to help with lookup service registration. However, since I did not have the previous fingerprint for the lookup service, I had to reinstall VR. I only used this for one VM, so it was not a major issue for me.

Virtual Infrastructure Navigator (VIN) (step 8) suffered the same problem as VR, so I also reinstalled that application. It will take some time for all the connections to be seen again: roughly one week. I also experienced an “Unable to load” error from within the vSphere Web Client related to VIN.

VMware Support Assistant (VSA) also gave me issues with an “Unable to load” error from within the vSphere Web Client. This tool was not part of my vCloud Suite bundle but could be downloaded separately. Once installed, it cleaned up another “Unable to load” error.  This is a reinstall, as it only ships as an OVA and since most everything is on the VMware site for support, there is no need to migrate anything over.

In clearing up all the “Unable to load” errors, I realized I also had issues with HP OneView, which has an update as of April 2015. This is something I missed when I last did an upgrade, in March, for this third-party component. Be sure to upgrade to HP OneView for VMware vCenter 7.6.

The Site Recovery Manager (SRM) (step 9) upgrade required me to have registered the proper version of VR. This led me down the road to reinstalling VR and VIN, as well as fixing HP OneView. Once those other items were fixed, then everything installed and worked fine within the vSphere Web Client.

vSphere Management Assistant (vMA) also needs to be upgraded, but since I do not modify this image, the only thing necessary to upgrade it is to replace it with the new OVF.

After all of those upgrades, I found that the best browser for the vSphere Web Client was Chrome, as the Client Integration Plug-in would not work properly with Firefox or IE, which is required for using the Deploy OVF menu item. In addition, I had to disable the “Use hardware acceleration when available” option within Chrome’s settings to get the vSphere Web Client pages (and other SSL-based pages) to appear when running Chrome within a VM, unless you wish to delete all content, history,  cookies, and cache from the browser every launch.

Now all the preparation work is completed before we upgrade vSphere ESXi itself.

Leave a comment

Your email address will not be published. Required fields are marked *

I accept the Privacy Policy

This site uses Akismet to reduce spam. Learn how your comment data is processed.