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.
I’m running my upgrade from a Windows Server 2016 VM so will need to mount the downloaded ISO, browse to <CD\DVD Drive Letter>:\vcsa-ui-installer\win32\ and launch the installer.exe.
Once the vCenter Server Appliance Installer launches, click Upgrade.
Via the Introduction tab, click Next.
Accept the EULA and click Next.
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.
When prompted, accept the Certificate Warning by clicking Yes.
Enter the FQDN of the ESXi host or vCenter Server, as well as the appropriate user credentials. Click Next when complete.
When prompted, accept the Certificate Warning by clicking Yes.
Via the Select Folder tab, choose an appropriate folder to house the new VM, and click Next.
Via the Select compute resource tab, select an appropriate host or cluster, and click Next.
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 Select deployment size tab, choose a Deployment and Storage Size and click Next.
Via the Select datastore tab, choose an appropriate datastore and click Next.
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.
Via the Ready to complete Stage 1 tab, review the settings and click Finish.
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
When you’re ready to proceed with Stage 2 of the upgrade, click Next.
The vCenter Server Appliance Installer will now connect to the source vCenter Server and perform a number of pre-upgrade checks.
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.
Via the Ready to complete tab, review the settings, ensure you have taken a backup of the source vCenter Server, and click Finish.
At this point the source VCSA will be shutdown while the configuration, historical data, and network configuration is exported to the new appliance. When ready, click OK.
Once complete, you will be notified that DHCP settings for Auto Deploy will need to be updated, as well as to the fact that vSphere 6.7 disables TLS 1.0 and 1.1. When ready, click OK.
Once complete, note the new appliance’s Getting Started URL and click Close.
Finally, browse to the new appliance’s Appliance Management address (https://<vCenter-Server-Appliance-FQDN>:5480).
Via the Summary tab, confirm the VCSA Version displays 184.108.40.20600.
Lastly, launch the vSphere Client and login via your usual means.
This concludes the vCenter Server Appliance upgrade to 6.7.
This is a great article! Did you happen to make that future post regarding the available disk space issue you ran into? I and another person are running into this and we are unsure of how to proceed.
Thanks Aaron! Unfortunately I’ve not gotten around to writing that particular article, but in a nutshell, my get-out-of-jail was to identify if I had any available storage with appropriate capacity (SSH to your vCenter Server, enter bash and list all available file systems via df -h). In my case (see the screenshot Stage 2 > 3. Select Upgrade Data), I used /storage/tmp2/ but created a new child directory (mkdir export). I then defined the location /storage/tmp2/export in the Export Directory field. The export data will be removed once the upgrade completes.
Alternatively, if you don’t have any disks with suitable capacity, you could add a new disk to your vCenter Server, initialise it, and use it as the Export Directory.
Hopefully that helps, but let me know if not and I’ll double-check things in the lab. Reminder to self – write the follow-up article 🙂
Hi Gareth, thanks for your aritcle. did you have time to write the article for the storage problem??