vSphere 7 – Changing VCSA Appliance Size (also for vSphere 6.7)

When deploying out a vCenter appliance (VCSA), you have to choose the size of the environment that you will be managing.  Some people truly understand their current size and their growth aspirations and can therefore make an informed choice of what size to choose.  Others are restricted by resource availability at the time of deployment or their environments grow faster than anticipated, and therefore their original choice may not be relevant in the coming years.

So how do you overcome this?  Well, there are various different options available, but there doesn’t seem to be much advice available on the best or a supported method to do this.  I’ll explain about a couple of the options below before moving onto an often overlooked method in more detail, which I have performed and is pretty straightforward.

The focus of this article is very much on vSphere 7 but the process should also work with vSphere 6.7 (although this has not been tested by me).  As always, the information provided in this article is from my testing and should be carefully considered before implementing it in a production environment.  I also do not take any responsibility for any data loss or corruption that may occur through following these instructions.

With that bit of information out of the way, lets look at the problem in more detail:

When deploying out out a new vCenter, going through the UI installer, you’ll be presented with a screen similar to below:

As you can see, there are a few options to choose.  These range from Tiny which will support up to 10 hosts or 100 VMs right up to X-Large which will support up to 2,000 hosts or 35,000 VMs.  Plus you also have the choice to select Large or X-Large storage options instead of the default storage size, if you are expecting to collect more detailed data or more frequent stats from your VMs and hosts.

The issue is, that once you have made your choice on the size of appliance, there isn’t any way within the resulting appliance to adjust the size at a later date.

Please also note that the information provided will only work with increasing the size of the appliance, not with reducing it.

What can we do about this?  Well, there are basically four options available:

Option 1:  Deploy Out New vCenter

This is a valid option if you have only just created the vCenter and realised that you made a mistake with selecting the size.  This becomes more of a problem once you have been utilising the vCenter for a while or are utilising Distributed vSwitches etc., as all of this information will need to be reconfigured and it can get more complex when discussing those distributed vSwitches.

Option 2:  Upgrade vCenter

This is actually a good option if you are planning on changing the version of the VCSA you are using.  During this process, the first stage of the upgrade process is to deploy out a new VCSA which allows you to choose the size for the appliance.  During Stage 2 of the process, it then transfers the data from the old appliance to the new appliance.  The downside of this is that you can only utilise this method if you are changing versions, such as vCenter 6.5 to vCenter 6.7, or 6.7 to 7.  You cannot use this method for minor releases, such as vCenter 6.7 Update1 to vCenter 6.7 Update2.  During the upgrade process, the wizard used checks the version of the current vCenter and only utilises the major vCenter version for the checks.

Option 3:  Perform a Manual Upgrade

This one is probably my least favourite option as we have to be certain that all elements that need to be modified have been thought about and modified in the correct way.  With this process, we are talking about adjusting CPU & Memory, storage sizes and internal settings to the sizes that would be utilised with a larger appliance.

Although, not advised by myself, the Virtual Potholes blog has written up a very thorough method of manually increasing the size of the VCSA here:

https://www.virtualpotholes.com/post/151039651400/how-to-resize-the-vcenter-server-appliance-vcsa

It is based on VCSA 6.0 and therefore I’m not sure if there are additional things that have changed in the later releases of the product.

Option 4:  vCenter File Based Backup & Restore

This is my preferred method and the method that we will explore further below.  The idea behind this is to perform a File Based Backup of the vCenter appliance (something that every vSphere administrator should be performing anyway, as image based backups are not fully supported).

The second part of the process, is then to utilise the ‘Restore’ option in the vCenter installer UI, which will deploy out a new VCSA (and will allow you to choose the size you want).  During Stage 2 of the process, it will then restore the data from the backup to the new VCSA.  At the end of the process, you should have a new VCSA in place, to the size that you need with all of the data from the original VCSA.

Let’s look at this in more detail and try to highlight some of the points to be aware of:

Before starting, I would advise that you note down the FQDN and IP Address details for the existing VCSA.  Please note that the FQDN needs to be exactly the same as the original for the later stages, including capitalisation.

1. Make a File Based Backup of the vCenter
   This can be performed from the vCenter Appliance Management Interface (VAMI) and will require you to have the backup performed to an FTP, HTTP, FTPS or HTTPS among other destinations.
   The following VMware link explains the process of configuring the vCenter backup:  https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vcenter.install.doc/GUID-3EAED005-B0A3-40CF-B40D-85AD247D7EA4.html
   Alternatively, VMwareBlog has posted a very good article, including screenshots of the whole backup and restore process, this is available here:
   https://www.vmwareblog.org/backup-restore-vmware-vcsa-6-7/
   As VMwareBlog has done such a good run through of the backup and restore process, I will not go into too much detail on the actual process but will highlight areas to be aware of.
2. Restoring the backup – Stage 1 – Deploy New vCenter
   Stage 1 is to mount up the vCenter Install ISO and run the Installer UI interface.  On the first screen you would then select the ‘Restore’ option.  During the process, you will be asked to point to the backup files created earlier.  As a word of caution, the wizard will check the location of the backup to make sure that the ‘backup-metadata.json’ file exists.  This file is actually in the same folder as the backup files which may be located in subfolders in the location you used for the backup.  As the wizard will not step through subfolders, you will need to provide all of the subfolders in the path for the backup file location.
   If you are asked to provide the server name details including IP Addresses, then these should be entered exactly the same as the original appliance details including capitalisation to avoid the wizard stopping the restore process.
   During this new vCenter build stage, you have the opportunity to choose the size of the appliance.  This gives you the opportunity to increase the size of the appliance in use, and you can make the decision based on the information shown in the screen shot above (if you are utilising vSphere 7).  The recommendation would be to make sure that the original appliance is turned off prior to the new appliance being turned on, as the new appliance will have the same network name and IP Address as the original appliance and could cause problems on your network, if they are both turned on at the same time.
3. Restoring the backup – Stage 2 – Restore the data
   With the new appliance deployed, you will then go into the VAMI interface and be presented with the Stage 2 wizard to finish the restore of the backup data.  At this point you will be asked to confirm the encryption password (if it is set), before the restore is performed.
   Once the restore process is complete, you should be able to access the vCenter normally again with all ESXi hosts and settings as they were before.  There shouldn’t be a requirement to reboot the vCenter before utilising it but I would recommend it.  If you do have issues with the new vCenter, you should be able to powered down the new vCenter and power up the original vCenter again.

Hopefully this information is useful for people looking at this type of issue.