You deployed a vCenter in a tiny configuration because initialy you didn’t have enough storage available or the demand for it and now you want to resize the appliance? Then this post is for you

Yes, there are multiple posts on this topic out there already. But none I could find would provide an (full) answer to the question: how to I change my configuration from e.g. the default configuration named tiny to the default configuration named large? Because nobody would provide information on what the actual specs comming with those configurations look like. Sure: if you got a capacity issue on a disk you just might increase that disk and be good with it. But some people like to roll with defaults. So I even asked the support to provide me with a list of those specs: nada. Of course, you could just deploy a new appliance and have a look at it but really: there must be a better way then deploying every possible configuration for every VCSA version just to get a full specification list.

JSON and JSON Schema fwd

So I remembered that the new VCSA installer is based on electron and is using JSON and JSON-Schema for configuration data and validation, which honestly is a great choice for a modern installer, if you ask me. This also means that most probably all the possible specifications for the various configurations such as tiny should be somewhere in a JSON file. It turns out: they are. On the VCSA installer ISO change to the directory \vcsa-ui-installer\win32\resources\app\resources, you’ll find a file called layout.json. It contains all the data we were looking for, for example the xlarge entry looks like this (VCSA 6.7U2):

"xlarge": {
        "cpu": 24,
        "memory": 49152,
        "host-count": 2000,
        "vm-count": 35000,
        "disk-swap": "50GB",
        "disk-core": "100GB",
        "disk-log": "25GB",
        "disk-db": "50GB",
        "disk-dblog": "25GB",
        "disk-seat": "500GB",
        "disk-netdump": "10GB",
        "disk-autodeploy": "25GB",
        "disk-imagebuilder": "25GB",
        "disk-updatemgr": "100GB",
        "disk-archive": "200GB",
        "required-disk-space": "1180GB",
        "label": "X-Large vCenter Server with Embedded PSC",
        "description": "This will deploy a X-Large VM configured with 24 vCPUs and 48 GB of memory and requires 1180 GB of disk space will be updated for xlarge later. This option contains vCenter Server with an embedded Platform Services Controller for managing up to 2000 hosts and 35,000 VMs."

So, if you need the default specs for your latest VCSA version: just look into the layouts.json and you got all you need. Now that we have the data: how to actually change the VCSA specs? This is already outlined in may other blog posts, but for the sake of completeness: let’s have a look!

Increase CPU (VCSA 6.7)

This one is easy:

  1. Note the hostname or IP address of the host that is running the VCSA VM
  2. If the host is part of a DRS cluster, it might be a good idea to switch DRS to manual mode. Remember that disabling DRS might delete things like ressource pools, so take care!
  3. Access the host client of the host that is running the VCSA VM and shutdown the VCSA VM
  4. Increase the CPU according to your needs or the default specs from the layout.json
  5. If required, move on to the next step before powering on the VCSA VM

Increase RAM (VCSA 6.7)

Previously this required running some scripts in the VCSA after the change but this is no longer required. So if you find some old blog posts that suggest you should run a script: ignore them if you’re on a VCSA >= 6.0. Basicly it’s the same process as with the CPU change:

  1. Follow the steps 1-3 outlined under Increase CPU (VCSA 6.7)
  2. Increase the memory according to your needs or the default specs from the layout.json
  3. If required, move on to the next step before powering on the VCSA VM

Increase HDD (VCSA 6.7)

The process of increasing the disks for VCSA 6.5 and 6.7 is detailed in KB2145603. There’s not much to add to it and since this might change with future releases I’d rather like to link to the KB then just rephrase what it sais.

However: there are some things that are not mentioned in the article and that are relevant. As we now already know you can get the default spec for the disk configuration from the layout.json file. The mapping JSON->VMDK happens in order, but the first two disks are skipped, since they are always deployed in the same size. For example (VCSA 6.7U2):

Purpose JSON pos VMDK nr SCSI slot
root / boot n/a 1 0:0
tmp n/a 2 0:1
swap 1 3 0:2
core 2 4 0:3
log 3 5 0:4
db 4 6 0:5
dblog 5 7 0:6
seat 6 8 0:8
netdump 7 9 0:9
autodeploy 8 10 0:10
imagebuilder 9 11 0:11
updatemgr 10 12 0:12
archive 11 13 0:13

Be careful when mapping the possition of the disk in the JSON file to a VMDK number. I have seen cases where the VMDK number did not match the SCSI slot. E.g. VMDK0 would be mounted on SCSI(0:4) and VMDK2 would be mounted on SCSI(0:0), thus VMDK2 would be the real root disk is this case, not VMDK0. Don’t get fooled by the VMDK name, it’s just a name and it can be wrong. What matters is the SCSI slot the disk is attached to. Also remember that by default the SCSI slot z:7 can not be used, so don’t forget to skip 0:7 when counting the possition.