This outlines the steps for performing an “End-to-End” upgrade of a vCloud deployment. “End-to-End” for the purpose of this guide refers to all aspects of the installation from the vCloud Director cells all the way to the deployed virtual machines running inside the vCloud. What this document will not cover is the specific click through steps on certain components, as those are documented in their respective installation guides or release notes. What this will cover are the dependencies, additional steps and considerations needed to maintain the proper working condition of the system at certain stages in the upgrade process and facilitate a smoother process. It is recommended that there are “planned” pause periods between phases to allow for validation and user testing before moving onto the next phase. Although all phases could be completed in a “Big Bang” approach this may add risk and troubleshooting difficulty.

IMPORTANT NOTE: Some of these upgrades may be disruptive to end users, and will require that they do not have system access for a brief period. This is unavoidable, and precautions should be taken for informing users. Running virtual machines will remain available in most cases. This will also NOT address the process for migrating from an Oracle-based vCloud Director Database to MS SQL Server, the process which is currently not supported.

Installation References

The following publications contain information on upgrading each individual component discussed in this document.

• VMware vCloud Director 1.5 Install Guide
  
• VMware vShield Manager Release Notes
  
• VMware vSphere 5 Upgrade Guide
  
  • vCenter Server
    
  • Update Manager
    
  • Orchestrator
    
• Chargeback Release Notes
• Reference all available KB articles as well.

Support and Assistance

Contact VMware Global Support for any assistance and always reference the available Knowledge Base Articles and product installation guides

High Level Process Outline

The upgrade has been divided into four major phases as shown in the order below. After completion of any phase, a customer can “park” indefinitely until they chose to move on.

Table 1 – Upgrade Phases

Each of these phases will be addressed with considerations in separate sections in this document. In testing the upgrade process and considering potential variations in the order of steps, the methodology presented here provided the most stable and phased approach to an upgrade. For example, a customer could elect to only perform Phase I and II and wait on any vCenter or ESXi upgrades and subsequent changes until they wanted the additional functionality. The choice of when to proceed further can be left up to the customer to decide, and they are not left in a state of instability.

There has been a question of upgrading vCenter and ESX first. The downside with upgrading ESX and vCenter before vCloud Director is that the vCloud Director 1.0.1 agent simply will NOT install on an ESXi 5 host. This means if you start the upgrade process with ESX first you will be forced into upgrading vCloud Director planned or unplanned. This may not be the best option for customers that want a truly phased methodical and systematic approach. However, in our tests we observed that upgrading vCenter only to version 5 did not adversely affect vCloud Director in any noticeable way other than Custom Roles are modified and may need to be updated.

Additionally, some customers have mentioned they want to upgrade to vCloud Director specifically for Oracle 11gR2 support or Microsoft SQL Server support, and want to wait on upgrading the vSphere end until they can test it elsewhere. The main point is once you start with vSphere first you will be forced to continue all the way through and have no real phased approach.

Upgrade Checklist

VMware vSphere

Table 2 – VMware vSphere Checklist

Software

Table 3 – Software Checklist

Service Accounts

Be sure to have all the service accounts available with passwords that were used for the original installation. The following table is a reference table of accounts that could have been used during installation and their mapping. Your customer’s use of service accounts may be different, and the key is to understand for each component what account was used, as this can affect the upgrade functionality. In the test lab each component was given their own unique service account in Active Directory (AD) to test the connectivity to other components. Some customers may NOT have used service accounts depending on the installation, but many of the new security features especially in vShield Manager will require them. The table below lists the most common access requirements and the level of access they will need. If these are not in place, they should be created prior to upgrading.

 

Table 4 – Suggested Service Accounts Used