I found that especially when you migrate Windows vCenter servers to the VCSA you might end up with a deployment size that is less than optimal. Some people say; don’t worry, it’s just thin provisioned. But I’m an old-school guy and I like to keep things neat and simple. The specific use case I have is a former Windows vCenter that ended up as an X-Large VCSA. At the time of the migration no other size than X-Large was presented in the interface even though the data was nowhere near the threshold for an X-Large deployment. As you can see in the following directory listing the /storage/seat mount point is 1.4TB even though there is only 56GB in use.

And sure enough, when I did a dry run to upgrade this vCenter apparently all the provisioned space is taken into account. Because the upgrade process only allows me to select X-Large because 2.2TB of storage is needed. Even if the sum of all the data is only about 150GB.

Product improvement tip! – If any VMware employee ever gets to read this blog post. Maybe you can make future VCSA upgrades only look at used disk space instead of provisioned space. ?

So I created a service request with VMware to see if there’s a way to reduce the deployment size during the upgrade. Unfortunately there was no documented procedure available. Even the guides and KB articles available on the internet only describe how to extend VCSA storage. So I decided to investigate if I could come up with a procedure of my own.

Turns out reducing disks – or volumes I should say – is actually very easy because the VCSA is using LVM. The required steps are:

  • Create a backup or snapshot before you begin the process
  • Stop the services: service-control --stop --all
  • Unmount the mount points you want to resize: umount /storage/seat/
  • Do a filesystem check: e2fsck -f /dev/mapper/seat_vg-seat
  • Resize the filesystem and make it a bit smaller than the size the volume will eventually become: resize2fs /dev/mapper/seat_vg-seat 9G
  • Set the logical volume to the desired size: lvreduce -L 10G /dev/seat_vg/seat
  • Now let the filesystem fill the rest of the logical volume: resize2fs /dev/mapper/seat_vg-seat
  • Mount the filesystem(s) you resized: mount /storage/seat/
  • And restart the services: service-control --start --all
  • Remove the snapshot if the procedure is successful.

On my test VCSA I resized the /storage/seat mount point and recorded the process using asciinema. There are a few extra steps I included for my environment to verify that a VCSA backup actually picks up on the resized mount point. But you can ignore those.

Also keep in mind that this procedure only resizes the mount points and logical volumes. This does not change the underlying disks themselves. But as this is intended a pre-upgrade procedure where you move everything over to a new appliance this is not an issue.


  1. You are my hero!.
    I am so glad you posted your procedure, how to reduce the storage size.
    In my case I wanted to upgrade a tiny vcsa6.5 to 6.7 in my homelab. The initial proposal of this funny upgrade software was Medium, which wouldn’t have fit into my small, phsical home lab resources.
    Thanks to your guide I can keep all the configuration and can smoothly continue to work with a tiny vcsa v6.7

    Thanks again for this great post,

    Jurgen Mutzberg
  2. We had 525GB seat and I did our upgrade using CLI where you can select standard disk size. This your guide was my backup solution, thanks for it. I have pointed our vmware TAM to this.

  3. Pingback: Resizing VCSA seat volume | NizMoTek IT Solutions

  4. After watching a video on how to backup and restore vCenter server using it’s inbuilt service. It mentions that the restored version has to be of the same size or bigger as the original server

    Do you think if i made the changes you detailed above, then made a backup, then did a restore it would have the same desired affect of reducing the volume sizes?

  5. I’ve done this an everything was successful but the size of the disk hasn’t reduced in vSphere, it shows the reduced size when running the command -df -h but not in vSphere or Veeam?

    Stuart Adams
  6. Thank you!! Very helpful. I had to shrink the underlying disk using CLI commands I found on another site and adding a new smaller disk. I tried with Standalone Converter, but it couldn’t connect to my live vCSA. So I had to do things “the hard way.” as I wasn’t upgrading but doing this in-place. Thanks again!

  7. Thank you! I really appreciate it. We had the issue after the previous upgrade from 6.5 to 6.7 the /SEAT partition was ballooned to 1.4 TB! Nobody, including the VMware support, had a reasonable way to fix it. We lived with it until upgrade to 7! When we run the installer, we have only one choice, X-Large size!!! With needed space of over 3TB…Your procedure helped us to bring the vCenter7 installation to what was appropriate to our organization.


Leave a Reply

Your email address will not be published. Required fields are marked *