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:
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.
Hopefully this information is useful for people looking at this type of issue.