With the release of vSphere 6.7 back in April 2018, a host of new enhancements, features, and goodies had the vCommunity going wild. With enhanced feature parity between the legacy vSphere Web Client and new HTML 5 vSphere Client, as well as the vCenter Server Appliance boasting performance increases of ~2X faster performance in vCenter operations per second, ~3X reduction in memory usage, and ~3X faster DRS-related operations (e.g. power-on virtual machine); these two areas alone made most of us want to upgrade. Nice.
vSphere 6.7 also boasts the new Quick Boot feature for vSphere hosts running the ESXi 6.7 hypervisor and above. This feature allows users to a) reduce maintenance time by removing the number of reboots required during major version upgrades (Single Reboot), and b) allows users to restart the ESXi hypervisor without having to reboot the physical host (essentially skipping the time-consuming hardware initialisation). Very nice!
Client feature parity isn’t there just yet though, so be aware that you’ll still need to jump between clients depending on the work you’re implementing. For example, management/configuration of NSX Logical Switches is yet to be brought into the new HTML 5 vSphere Client, however, VMware have announced that they are targeting a full feature parity version later this year (Fall 2018). More information on this announcement, as well as future feature parity releases can be viewed here. Stay tuned to the Functionality Updates for the vSphere Client for more info.
Furthermore, vSphere 6.7 now adds support for Trusted Platform Module (TPM) 2.0 hardware devices, as well as introducing Virtual TPM 2.0.
Data encryption (introduced with vSphere 6.5) has been further enhanced in vSphere 6.7, with VM Encryption now ‘more operationally simple to manage’. This ensures data is protected at rest, in motion, and enables encrypted vMotion across different vCenter instances and versions.
Lastly, as VMware continues to support the adoption of vSphere-based public clouds such as VMware Cloud on AWS (as well as other public cloud providers), for example, vSphere 6.7 now introduces vCenter Server Hybrid Linked Mode for a more seamless hybrid cloud experience. This boasts a simplified, more unified experience for visibility and management of both on-premises and public cloud vSphere environments
In this post I cover the the process of upgrading a vCenter Server Appliance with embedded Platform Services Controller (PSC). If you have an externally deployed PSC(s), you’ll need to update these first, before upgrading your vCenter Server Appliance.
The upgrade itself can be broken down into two simple stages which, incidentally, mirrors the procedure used when migrating from a Windows-based vCenter Server to the vCenter Server Appliance.
- Stage 1 will deploy a brand new appliance, thereby protecting your running VCSA from any potential upgrade issues, misconfiguration, or errors.
- Stage 2 exports all data and configuration to the new appliance. Were any issues to be experienced during the upgrade, the new appliance can simply be deleted, and the original appliance powered-on.
Before you start upgrading, I must point out a few important items:
- VMware Compatibility Guide – with the release of vSphere 6.7 (and specifically, the ESXi hypervisor), a number of processors were dropped from support. This in itself, can be a show stopper, so ensure your hosts (and their processors) are compatible before upgrading your hypervisors.
- vSphere 6.7 Release Notes
- Update sequence for vSphere 6.7 and its compatible VMware products (53710) – Ensure your environment is upgraded inline with the recommended and supported update sequence.
- Ensure to take a backup of your current VCSA.
- Disable DRS on the cluster housing your current VCSA.
Stage 1 – Appliance Deployment
First up, visit My VMware and download the latest version.
Connect to your source/existing VCSA via FQDN or IP address, enter the SSO credentials, and add the credentials for either the vCenter Server or host which currently manages the appliance. Once done, click Next.
Note, for clarity, I’ve entered the VCSA FQDN for both appliance and for the ‘ESXi Host or vCenter Server’ fields.
Via the Set up target appliance VM tab, give the new appliance an appropriate label and root password, and click Next.
Note, the new appliance will eventually retain both hostname and IP of the original. To keep the original VM label, you will have to change both the current appliance label and underlying VM datastore folder. I recommend performing this post-upgrade by a) renaming the legacy powered-off VM and datastore folder, then b) by renaming the new VM and it’s datastore folder, followed by a Storage vMotion to a different host in your cluster.
Via the Configure network settings tab, enter all details accordingly and click Next.
Note, these are temporary network settings. The original VCSA configuration WILL be retained.
Monitor the appliance deployment and note the new VM is created and powered-on.
Finally, Stage 1 will complete. When ready, click Continue to begin the configuration migration straight away or, if you need to run the next stage within a later maintenance window, click Close and revisit the relevant link at a later time. Note, up until this point, there will be zero loss of service, all thanks to the upgrade deploying a new appliance for future configuration.
Stage 2 – Migration of Configuration, Historical Data, and Network Configuration
Via the Select upgrade data tab, choose which data you wish to maintain and, where that data exceeds the standard Export Directory (/) usable capacity, configure a new directory (as I have done below).
Note, I experienced a number of failures due to this part of the upgrade process. Initially, I wanted this temporary export data to sit on a temporary disk. As such, I added a new disk to my source vCenter, initialised it, and mounted it, however, the vCenter Server Appliance Installer failed to see this new disk and directory. In the end, I created a new directory on an existing disk which had enough free space. I will expand on this issue in a future post.
When ready, click Next.
Via the Configure CEIP tab, opt in or out of the VMware Customer Experience Improvement Program, and click Next.
Note, with the recent enhancements and announcements around the ability for VMware to dive much deeper into your environment during the life of a support case, I’d recommend you start opting-in to the CEIP. vSAN alone has seen some significant support improvements due to such CEIP opt-ins. More on this via Duncan Eppings post from May 2018, How to simplify vSAN Support.
Lastly, launch the vSphere Client and login via your usual means.
This concludes the vCenter Server Appliance upgrade to 6.7.