Upgrading vCenter Server Appliance 5.0.x/5.1 to 5.5

Prerequisites
To upgrade vCenter Server Appliance from 5.0.x/5.1 to 5.5:
  1. Deploy the new version of the vCenter Server Appliance. For more information, see Downloading and deploying the vCenter Server Appliance 5.x (2007619).

    Note: The new appliance has a default network configuration and the VMware VirtualCenter Server service is not configured and is disabled. There is a known issue were the vCenter Server Appliance will not change the hostname when deployed. For more information, see VMware vCenter Server Appliance 5.5 sets a wrong hostname after deployment (2065275)

  2. Connect to both the old and new appliances in separate browser windows. For example, use a URL similar to https://ip_address_of_vCenter_VM:5480.
  3. In the new appliance, start the vCenter Server Setup wizard and accept the end user license agreement.
  4. In the Configure Options panel, select Upgrade from previous version and then click Next.
  5. Copy the key from the Import this key section into the source appliance field.
  6. If you are upgrading vCenter Server Appliance 5.0.x to 5.5:
    1. In the old vCenter Server Appliance 5.0, click the Appliance Upgrade tab.
    2. Select source for the appliance role and click Setrole.
    3. Click Establish Trust.
    4. Paste the local appliance key into the Remote appliance key field.
    5. Click Import remote key.
    6. Copy the local appliance key.
    7. In the new vCenter Server Appliance 5.5, paste the local appliance key into the Remote appliance key field and click Next.
  7. If you are upgrading vCenter Server Appliance 5.1 to 5.5:
    1. In the old vCenter Server Appliance 5.1, paste the key from Step 5 into the Upgrade key field.
    2. Click Import key and Stop vCenter Server.
    3. Copy the Upgrade key.
    4. In the new appliance, paste the Upgrade key to the Paste the source appliance key into the field below field and click Next.
    5. If there are issues detected with your SSL certificates, select the Replace the SSL certificates option. You are prompted for SSO password for user administrator@vsphere.local.

  8. In the new vCenter Server Appliance, click Next.

    Note: The new appliance shuts down the old appliance and assumes the network identity (IP address, hostname, and network configuration) of the old appliance after the transfer has completed. This process can take some time and the virtual machines may appear unresponsive during the transfer. If the old appliance was configured to use dynamic addressing, the new appliance also uses dynamic addressing. When the import completes, the new vCenter Server Appliance starts.

  9. Review the list of hosts managed by the source appliance and ensure that all hosts to be managed by the new appliance are selected.
  10. Review the pre-upgrade check of the source appliance hosts and correct any errors before proceeding.
  11. Confirm that you have taken a backup or snapshot of the source appliance and the external database and click Next.
  12. (Optional) To follow the upgrade process, open an SSH session to the new vCenter Server Appliance and run this command:

    tail -f /var/log/vmware/vami/upgrade.log

    Note: This also helps in identifying where the process has stopped, if there are any issues with the upgrade.

  13. When the upgrade completes, click Close. vCenter Server Appliance is now upgraded and the new appliance reboots.

Microsoft Patch causing SSO Handshake Timeouts with Horizon View 5.2

Every second Tuesday of the month Microsoft releases patches for the different operating systems and running applications of the vendor.  Before applying those patches to the operating systems and applications, an extensive testing process is needed. When all patches are behaving correctly the can be applied to the environment. When the extensive testing isn’t fulfilled completely, this can cause some strange behavior. At a customer site which is running a VMware Horizon View 5.2 environment this causes problems within their vCenter deployment.

One of the patches wasn’t tested enough and causes after patching and restarting the server an non functional vCenter Services. Within the log files different message directing to problems with connecting to the vCenter SSO services.

2014-02-20T06:43:08.260+01:00 [04512 error ‘Default’] SSLStreamImpl::BIORead from SSL(TCPClientSocket(this=00000000080f42d0, state=CONNECTED, _connectSocket=TCP(fd=-1), error=(null)) TCPStreamWin32(socket=TCP(fd=500) local=<IP vCenter Service>:56161,  peer=<IP SSO Service>:7444)) timed out
2014-02-20T06:43:08.260+01:00 [04512 error ‘Default’] SSLStreamImpl::DoClientHandshake for SSL(no stream): SSL_connect failed with BIO Error
2014-02-20T06:43:08.260+01:00 [04512 error ‘HttpConnectionPool-000001’] [ConnectComplete] Connect failed to <cs p:000000000abf25c0, TCP:grnap756.duo.local:7444>; cnx: (null), error: class Vmacore::Ssl::SSLHandshakeTimeoutException(SSL Exception: The SSL handshake timed out local: <IP vCenter Service>:56161 peer: <IP SSO Service>:7444.)
2014-02-20T06:43:08.260+01:00 [04440 error ‘[SSO][SsoCertificateManagerImpl]’] [CreateAdminSsoServiceContent] SSLHandshakeTimeoutException while trying to connect to SSO Admin server: SSL Exception: The SSL handshake timed out local: <IP vCenter Service>:56161 peer: <IP SSO Service>:7444.).

The VMware knowledge base article 2036170 wrote about patches which could be the source of the problem. With this customer new patches were placed on those systems the same morning. After some digging around in the patches one of them popped out. Patch 2862973 made changes to the MD5 hashing algorithm for Microsoft root certificates. And especially for server authentication which was used on this particular environment. After removing the patch on the systems, we we’re able again to start the vCenter Services.

vCenter with Oracle 11g

The latest release of VMware vCenter 4.1 is capable of using difference database systems, mostly these installations are done on SQL databases. But also DB2 and Oracle databases are supported. At a customer site is Oracle 10g used as a default for all databases. Within a few months the customer will upgrade these databases to Oracle 11g. Using these difference versions for now and in the feature, we decides to use the Oracle 11g client for installing vCenter and View Composer. The Oracle Install Client 11g is used for connecting to the Oracle 10 database.

vCenter will be placed on a Windows Server 2008 R2 Enterprise with slipstreamed SP1, and is using a double vCPU with 4 GB of RAM.

Before the ODBC connection to the database can be made, the Oracle 11g client is places on the vCenter server, therefore the Oracle version 11 packages are extracted to C:\Oracle

  • instantclient-basis-windows.x64-11.2.0.2.0.zip
  • instantclient-odbc-windows.x64-11.2.0.2.0.zip
  • instantclient-basic-win64-10.2.0.5.zip

After that the odbc_install.exe is executed for making the client software available within the ODBC connection software. A default tnsnames.ora Oracle configuration file, created by the customer is stored in the created sub folder NETWORK\ADMIN, which results in:

C:\Oracle\instantclient_11_2\NETWORK\ADMIN\tnsnames.ora

The installation of the Oracle 11 Client have been finished with these steps.

The next step is creating the ODBC connection to the database, the following steps are used for creating these connection:

Start Data Sources (ODBC) within Administrative Tools, and create a new System DSN

Select the Oracle in instantclient 11_2 and hit the Finish button

Supply the needed information for the connection and use the Test Connection button for testing the connection.

After these steps the installation of vCenter can be done and the created DSN can be selected during the installation and the connection will be used for filling the database.

The latest step is the extraction of the ojdbc14.jar file from the Oracle instant 10 client, and place the file in the <vCenter Install Location>/Infrastructure/tomcat/lib folder