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.

root@vcsa02 [ ~ ]# df -h
Filesystem                                Size  Used Avail Use% Mounted on
devtmpfs                                   24G     0   24G   0% /dev
tmpfs                                      24G   20K   24G   1% /dev/shm
tmpfs                                      24G  676K   24G   1% /run
tmpfs                                      24G     0   24G   0% /sys/fs/cgroup
/dev/sda3                                  11G  6.0G  4.1G  60% /
tmpfs                                      24G  948K   24G   1% /tmp
/dev/sda1                                 120M   28M   87M  24% /boot
/dev/mapper/updatemgr_vg-updatemgr         99G  1.5G   92G   2% /storage/updatemgr
/dev/mapper/autodeploy_vg-autodeploy       25G   69M   24G   1% /storage/autodeploy
/dev/mapper/log_vg-log                    148G   43G   99G  31% /storage/log
/dev/mapper/dblog_vg-dblog                 25G  9.7G   14G  42% /storage/dblog
/dev/mapper/imagebuilder_vg-imagebuilder   25G   45M   24G   1% /storage/imagebuilder
/dev/mapper/netdump_vg-netdump            9.8G   23M  9.2G   1% /storage/netdump
/dev/mapper/core_vg-core                   99G   60M   94G   1% /storage/core
/dev/mapper/db_vg-db                      296G   19G  265G   7% /storage/db
/dev/mapper/seat_vg-seat                  1.4T   56G  1.3T   5% /storage/seat
tmpfs                                     1.0M     0  1.0M   0% /var/spool/snmp

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.


Rudolf Kleijwegt

I am an experienced IT professional with over 20 years of hands-on experience designing, deploying, and maintaining IT infrastructure in both enterprise and service provider environments. My skills span across Linux and Windows and a multitude of server applications, allowing me to excel in a wide range of IT roles. Currently, my primary focus is on Software Defined DataCenter and DevOps. I am passionate about staying up to date with the latest trends in the industry to achieve superior outcomes.

11 Comments

Jurgen Mutzberg · October 9, 2019 at 7:53 pm

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

fsck · February 5, 2020 at 10:11 pm

Thank you! I ended up with storage/seat 1,4 TB as you and now I decreased it followed your guide….Big thanks!!

Ivan · March 30, 2020 at 1:21 pm

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.

Rob · July 3, 2020 at 5:27 am

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?
https://www.youtube.com/watch?v=r05k2AeQgcU

    Bryan van Eeden · July 13, 2020 at 5:53 pm

    Well I do believe we tested this, and the result was not satisfactory… But as things change with updates, it might work this time around.

Juho Syrjänen · October 12, 2020 at 9:42 am

Thanks, this is a good summary on how to tackle this annoying issue. 🙂

Stuart Adams · February 5, 2021 at 12:48 pm

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 · February 5, 2021 at 1:54 pm

    I reread it, thanks!

Bill · March 5, 2021 at 2:17 pm

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!

Mario · July 23, 2021 at 7:29 pm

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.

Resizing VCSA seat volume | NizMoTek IT Solutions · April 23, 2020 at 1:49 pm

[…] How to shrink VCSA logical volumes before an upgrade ← Previous Post […]

Leave a Reply

Avatar placeholder

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