Step by Step: Upgrade vCenter VCSA 6.0 (or 6.5) to 6.7

, , , , , , , , , , , 32

These screenshots show the entire process to upgrade vCenter from 6.0 to 6.7 using a Windows 10 desktop as my administrative workstation.   The same steps work for vCenter 6.5 to 6.7.

Is your existing vCenter server running on Windows?  This article is primarily about upgrading vCenter appliances (linux-based).  If you have a Windows vCenter server, check the comments for instructions from Greg Curry.  Thanks Greg!

 

Preparing for the vCenter appliance upgrade

First, create a snapshot for your existing vCenter server. If you have disk space available, make sure to Quiesce memory.
Log on to vmware.com and navigate to the Downloads section. Pick vCenter Server from the list. (It does not matter if you choose Essentials, Standard, etc, they are all the same).
Verify the version you want to use (it will default to the latest one), and click Download for VMware vCenter Server Appliance, file type = iso.   Now wait for a bit for it to download.
Navigate to your downloads folder when the download completes. In Windows 10, you can double-click the file to mount it to a virtual DVD drive. For non Windows workstations, use an .iso viewer or burn the image to a CD then open it on the CD.
Navigate to the contents of your .iso file. On Windows 10, use Windows Explorer and look for the files inside your DVD drive.  Then expand vcsa-ui-installer to open that folder.
Expand the folder  that matches your computer (Windows 7, 8, and 10, pick win32)
(Windows 7, 8, 10) Run the installer.exe file to start the upgrade wizard.

Appliance Upgrade Stage 1

Options display. For this scenario, pick Upgrade (to upgrade an existing vCenter appliance from 6.0 or 6.5 to 6.7)
The VCSA introduction screen displays.
Agreement displays. You need to accept it to proceed.
Enter the DNS name for your existing vCenter server.  You can look this up in the address bar when you open vCenter to manage your VMware environment.  Port 443 is appropriate for almost everyone, unless the IT department has customized this.  When you Connect to Source, the rest of the window will display.
Most environments will use administrator@vsphere.local for the SSO User name.  SSO password is the password for the user name you entered above (administrator@vsphere.local).  Appliance (OS) root password means the root password for your vCenter appliance website (https://vcenter01.company.com:5480).  See next step to identify which ESXi host is managing your appliance.

——————

Additional info from Todd who provided this quote in the comments (Thanks Todd!)

I ran into one minor issue during the “Upgrade Stage 1: Deploy Appliance” phase. Operation would halt with “Failed to authenticate with the guest operating system using the supplied credentials.” I know they’re good as I can login to VCSA, VAMI, MOB, ESXi using them.

I changed all of the passwords to numbers and letters only with a single known good special character tacked on at the end. Et Voila! Problem solved. The rest of the upgrade proceeds without errors.

Passwords like these will not work with this utility:

Tv5$8FG#m*Djn
7xjg8sP%C#usXH8H
X8xk$vR^q9ccw@WxR

———————–

 

In the VMware hosts & clusters view, if you select your existing vCenter server and go to the Summary tab, you can see the address of the ESXi host.
You will get prompted to review the certificate. Just click Yes.
Now enter the ESXi server that will host your upgraded vCenter server.  Yes, we are making a new vCenter server with this procedure.  The old vCenter will be powered off if the upgrade succeeds.   Make sure you pick a host that has plenty of RAM and disk (at least 12 GB RAM, at least 500 GB disk) available.
This is where you set the name and password for your new vCenter.   The name will be displayed in VMware Hosts & Clusters.  This is not the DNS name or IP address for your new vCenter.  Your new vCenter will inherit the existing DNS name and IP address since we are doing an upgrade.
Almost all medium and small businesses use Tiny for deployment size and Large for storage size.    If you have 10 or less ESXi servers, use Tiny.
Pick the datastore that will host your new vCenter server.  Remember that by default it will use 850 GB thick provisioned for a Tiny deployment.

Optional:  Check the “Enable Thin Disk Mode” so that your vCenter server uses less disk space (about 80 GB).  This is mildly dangerous because the usage can grow over time and cause a datastore to fill up (crashing all VMs on the datastore), but for most small environments it doesn’t grow more than a few GB per year and 850 GB is WAY more than you need. 

These are the network settings that your new vCenter server will use.  Make sure to pick a Network that both your existing vCenter and the new vCenter can communicate on, with their IP addresses.  The new vCenter will use the Temporary IP address for a few minutes during the upgrade process, then it will switch to the existing IP address of your vCenter server.    Make sure no other devices are using the Temporary IP address.
Ready to complete displays.  When you click Finish, the deployment will start.
Even across WAN links, this process takes less than an hour.    Make sure that your workstation doesn’t disconnect from the work network during this process.  (If it does disconnect, no problem, just re-start from the beginning.)

Errors that can occur during stage 1

If you used the wrong password for the old vCenter, the source host, or the destination host, you may get an error at this point.

If you are on an unstable VPN link, you may get an error.  Try running the upgrade from a workstation or server on the LAN.

If you used DNS instead of IP addresses, try changing to IP addresses.

Temporary IP error: The upgrade will attempt to ping the IP address you chose for the temporary vCenter IP address.  If it pings, the upgrade will fail.  Make sure nothing is using that IP.

For information about cleaning up failed upgrade steps, see troubleshooting at the bottom of the article.

Stage 2 Upgrade VCSA

Phase 1 shows complete. The new vCenter virtual machine is deployed, but not configured. Beginning Phase 2 of the upgrade.
Introduction for Stage 2 displays.  Click Next.
It is normal to get several warnings.  Errors are bad, and will cause your upgrade to fail. Warnings are not bad.   Read them and take action if appropriate.
Most small and medium businesses don’t have that much data in their vCenter.  In this example, there is only 3.18 GB of data to transfer.   Since there is not a big difference between the sizes of each choice, I choose to move over everything.  It is good to retain historical data when possible.
Most businesses are fine to join the CEIP. If you are working on a secure network, then don’t check it.
Ready to complete displays.   You will need to check that you have backed up the source vCenter server (you did, right?).  Ways to perform backups:  1) Veeam. 2) Create that snapshot at the beginning of this post. 3) Use the appliance website (https://vcenter.company.com:5480) and click the Backup button (you will need a web server or SCP host to do this).   The reality is that this upgrade process doesn’t delete your original server. At the worst, it powers it off.  There is very little risk of harming your original vCenter.
Phase 2 proceeds.  It should finish within about 30 minutes.

Possible errors during phase 2

NTP error:  Make sure your source VCSA has good NTP settings which are the same as the host you are using for source and destination.  See this VMware article about configuring NTP.   https://kb.vmware.com/s/article/57146   If you don’t have an internal time server, then the recommended option is to point to internet NTP servers: 0.vmware.pool.ntp.org    ;  1.vmware.pool.ntp.org  ; 2.vmware.pool.ntp.org

Success!!

At this point, your upgrade should be successful.   When the upgrade wizard completes, your old vCenter will be powered off and your new vCenter (running 6.7) will be powered on.

You may want to rename your old vCenter to something like “old_vCenter01”.

Test your ability to log onto the vCenter appliance (https://vcenter01.company.com:5480)

Test your ability to manage your virtual machines (https://vcenter01.company.com/vsphere-client)

Make sure to check your backup jobs.  They should switch to using the new vCenter automatically, but double-check.

Once you are comfortable with the new vCenter and you have at least one good backup of it, you can delete your old one.

Remember that if the new vCenter doesn’t work, you can revert your changes simply by powering it off and powering the new vCenter on.  You may need to log into individual hosts (https://host_ip_address) to do this if your vCenter isn’t working.

Troubleshooting:

Manually verify every password for each device (your existing vCenter administrator@vsphere.local, your existing vCenter root, the source ESXi host root, the destination ESXi host root).  It is common for the vCenter root to be expired.  See my other blog for easy steps to fix an expired vCenter root password.

Orphaned vCenter attempts:  If your deployment fails, the new vCenter may display as orphaned.  There is no impact at this time, because you will continue using your existing vCenter.  I’ve heard that using VMware Workstation to connect to your vCenter will allow removal.  There is a blog that describes various methods for dealing with orphaned VMs: https://www.altaro.com/vmware/how-to-deal-with-orphaned-virtual-machines/  For a more authoritative source, see VMware KB article for removal steps: https://kb.vmware.com/s/article/1003742#vmdeleted

Upgrade failed with “Failed to send http datainstaller…”  The fix seems to be not using DNS for anything.  Change all your server names to IP addresses!   Reference https://virtuallyinclined.com/2018/07/30/vsphere-6-7-vcsa-upgrade-issues/

Selfish plug time (sorry!)

Thanks for reading this article! I hope it helps you! If you have tips or feedback, please comment or send me an email so that others can benefit.

I am a consultant in the Maryland/DC area in the USA. My specialties are Windows migrations (to 2016 and to Office 365 / Azure), VMware migrations, Netapp and SAN, and high availability / disaster recovery planning. If you would like help with your complex project, or would like a architectural review to improve your availability, please reach out! More information and contact can be found on the About page. – Amira Armond